PHP2Shell Crisis: Which Major Websites Went Offline, and Why

PHP2Shell Crisis: Which Major Websites Went Offline, and Why

Several government portals, educational institutions, and commercial websites went offline on October 21, 2026, as organizations rushed to respond to two critical security vulnerabilities in PHP, one of the internet’s most widely used programming languages.

The vulnerabilities, collectively nicknamed PHP2Shell, prompted cybersecurity agencies to recommend immediate patching. Organizations that could not secure exposed systems quickly were advised to consider taking them offline until the necessary fixes were applied.

The response affected services in multiple countries, including the Netherlands, Germany, France, Belgium and Finland. However, a precautionary shutdown does not mean that a website was successfully hacked.

What Is the PHP2Shell Security Crisis?

PHP is a server-side programming language used to power dynamic websites and applications. WordPress, Drupal and Joomla are among the platforms that can rely on PHP.

On October 21, 2026, the PHP development team released security updates addressing two critical vulnerabilities:

  • CVE-2026-109618: A vulnerability involving out-of-memory corruption.
  • CVE-2026-109619: A vulnerability involving stale global state.

Both vulnerabilities received a CVSS v4.0 severity score of 9.2 out of 10. Under certain conditions, successful exploitation could allow an unauthenticated attacker to execute malicious code on an affected server.

The potential consequences include unauthorized access to sensitive information, disruption of services and further compromise of connected systems.

The US National Security Agency (NSA) and European cybersecurity authorities urged organizations to identify vulnerable systems and apply the relevant security updates.

Which Major Websites and Services Went Offline?

According to Reuters reporting published on October 21, multiple organizations temporarily disabled public-facing services as a precaution.

The following are among the notable reported cases.

1. Dutch Government Portals

Several Dutch government services were temporarily taken offline during the security response.

Affected services included:

  • DigiD: The Netherlands’ government digital identity and login service.
  • MijnOverheid: The government’s online portal for citizens.
  • Overheid.nl: A government information portal.
  • Tweede Kamer: The Dutch parliament’s website.
  • NCSC-NL: The Dutch National Cyber Security Centre’s website.

The shutdowns were intended to reduce exposure while affected systems were secured. Outage tracking recorded several of these services returning later on October 21 or October 22.

2. French Government Websites

France’s Interior Ministry temporarily took the websites of several local government prefectures offline while awaiting a security fix for the affected software framework.

The move was precautionary, intended to reduce the risk of exploitation before the necessary remediation could be completed.

3. German Federal Websites

Germany’s federal IT service provider, ITZBund, temporarily disabled several websites following the discovery of the vulnerabilities.

A spokesperson for the German digital ministry told Reuters that the shutdowns were preventive and that no security incidents were known to have occurred at the time.

4. Belgian Foreign Affairs Websites

Belgium’s Foreign Affairs Ministry temporarily took its websites offline following reports of attacks exploiting the PHP vulnerabilities.

However, Belgium’s cybersecurity centre said it had not recorded attacks against Belgian websites at that point. This distinction is important: the precautionary response should not be interpreted as confirmation that those websites had been compromised.

5. Finnish Government Web Services

Finland’s state IT centre, Valtori, temporarily shut down public government web services.

The organization described the decision as a precautionary measure and said it had not identified attempts to exploit the vulnerabilities. The disruption was not reported as the result of a data breach.

6. Wikimedia Foundation Systems

The Wikimedia Foundation, which operates Wikipedia and other projects, confirmed that its PHP-based systems were affected by the vulnerabilities.

The foundation said it was addressing the issues and had taken some systems offline as a precaution until they could be safely patched.

This is particularly significant because Wikimedia supports widely used online information services that depend on large-scale web infrastructure.

7. Port of Rotterdam and Dutch Football Association

The Port of Rotterdam and the Royal Netherlands Football Association (KNVB) were also among the organizations whose websites were reportedly taken offline.

These cases illustrate that the response extended beyond government services to commercial, sporting and other public-facing organizations.

8. Other Organizations and Online Services

Reuters also reported precautionary actions involving organizations such as the Internet Archive, while other services were listed in contemporaneous outage tracking.

Not every reported outage had the same cause, duration or level of official confirmation. Each incident should therefore be assessed individually rather than assuming that all unavailable websites were affected in precisely the same way.

Why Did Organizations Take Websites Offline?

Taking a website offline can seem like an extreme response, but it may be a reasonable temporary security measure when a serious vulnerability affects an internet-facing system.

There are three main reasons.

1. To Prevent Potential Server Compromise

The PHP2Shell vulnerabilities could allow attackers to execute malicious code on vulnerable servers without first authenticating.

If an exposed server cannot be patched immediately, temporarily removing it from public access can reduce the opportunity for attackers to exploit the flaw.

2. To Allow Emergency Patching and Testing

Organizations need to identify which systems use affected PHP versions, determine whether third-party software is involved, apply the appropriate updates and test the results.

Large organizations may have hundreds of websites, applications and connected systems to review. Some components may depend on software vendors that need to release their own fixes.

3. To Protect Sensitive Data and Connected Systems

A compromised web server can expose more than the website itself. Depending on its permissions and network access, it may provide a path to databases, credentials or other internal resources.

Temporary isolation can help limit this risk while security teams investigate and remediate affected systems.

The NSA specifically recommended that organizations unable to update immediately consider taking vulnerable systems offline until they can be fully mitigated.

Does a Website Going Offline Mean It Was Hacked?

No. A shutdown is not proof of a successful cyberattack.

There are important differences between these scenarios:

  • Precautionary shutdown: An organization disables a vulnerable system to reduce risk.
  • Security patching: A service becomes temporarily unavailable while updates are installed and tested.
  • Confirmed compromise: Investigators establish that an attacker successfully accessed or altered a system.
  • Unrelated outage: A website is unavailable for another reason, even if the outage occurs during the same period.

In the PHP2Shell response, several organizations explicitly described their actions as precautionary. Others reported that they had not identified exploitation attempts.

It is therefore important to distinguish confirmed security incidents from preventive maintenance when reporting on affected websites.

What Should WordPress and PHP Website Owners Do?

The incident also matters to smaller websites, publishers and businesses that depend on PHP.

Website owners should take the following steps:

  1. Check the PHP version. Identify the version used by the production website, not just a local development environment.
  2. Apply the relevant security updates. The PHP releases addressing these vulnerabilities include 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Use a supported release containing the fixes.
  3. Contact the hosting provider if necessary. Managed hosting providers may control PHP updates or use different PHP configurations across services.
  4. Review third-party software. Check whether plugins, frameworks, applications or other components bundle or depend on vulnerable PHP versions.
  5. Review logs and security alerts. If the server was exposed while vulnerable, investigate suspicious activity rather than assuming that patching alone resolves every possible issue.
  6. Use temporary isolation if necessary. If an exposed system cannot be secured promptly, follow your security team’s risk assessment and applicable official guidance on restricting access.

The NHS England cybersecurity advisory also identifies affected PHP version ranges and recommends patching vulnerable systems. PHP 8.1 and older releases are end-of-life and require migration to a supported release rather than relying on new upstream security fixes.

What Does the PHP2Shell Crisis Reveal About Internet Infrastructure?

The response demonstrates how a vulnerability in a shared software component can affect organizations across different sectors and countries.

A government portal, an online encyclopedia and a commercial website may serve entirely different purposes while relying on the same underlying programming language or third-party software.

When a critical flaw affects that shared component, organizations must quickly determine where it is used, whether their systems are exposed and how to apply the necessary fixes.

The crisis also highlights the importance of software inventories, supported software versions, coordinated vulnerability disclosure and effective patch-management processes.

The Bottom Line

The PHP2Shell incident triggered precautionary shutdowns across government, educational, nonprofit and commercial services as organizations worked to address two critical PHP vulnerabilities.

Many of the reported outages were temporary security measures, not evidence that the affected organizations had been hacked. The immediate priority was to patch vulnerable systems, reduce exposure and restore services safely.

For website owners, the central lesson is straightforward: maintain an accurate inventory of server-side software, apply security updates promptly and investigate potential compromise when there is evidence of suspicious activity.

Editorial note: This article reflects reporting and advisories available around October 21–23, 2026. Outage status can change quickly; verify individual services’ current status and any subsequent security disclosures before publication.

Enjoy Worthview?

Add Worthview as a Preferred Source on Google to see more of our stories in Search.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.