Critical PHP Flaws Took Websites Offline Worldwide: What Happened and How to Patch

On Wednesday, 21 October 2026, a patch for one of the most widely used pieces of software on the internet sent governments, hospitals, broadcasters and online communities scrambling. Two critical flaws in the PHP programming language can, under the right conditions, let an attacker run code on a web server without logging in, and several national cyber-security agencies told organisations that could not patch in time to take their sites offline.

If you run a website, or depend on one for your business, this is the security story that matters this week. Here is what happened, why it spread so far, and what to do now.

What the two PHP flaws actually are

PHP is the server-side language that assembles a page before it reaches your browser. According to CNBC, citing web technology tracker W3Techs, it runs roughly 75% of websites whose programming language can be identified, and it is the engine behind WordPress, which powers about 43% of all websites.

The PHP Foundation described the two issues this way:

• CVE-2026-109618 (memory corruption on out-of-memory errors). If a request hits PHP's memory limit at exactly the wrong moment, PHP can leave half-built internal data behind and later treat it as valid. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings.
• CVE-2026-109619 (stale state after fatal errors). A fatal error at the wrong point can leave internal state pointing at memory from a previous request, which a later request on the same worker may then use.

The European Union's computer emergency response team, CERT-EU, rates both at CVSS 9.2 out of 10 and says every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with modphp, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers modphp the highest-risk setup.

The fixed releases are:

Sources: PHP Foundation, CERT-EU advisory 2026-018.

Why so many websites went dark at once

The plan was a quiet, coordinated release. It did not stay quiet. According to the PHP Foundation, the CVE numbers began circulating on forums and social media around 15:00 UTC on Tuesday, 20 October, with a wrong release time and an inflated score of 10.0. The project brought its pre-announcement forward and moved the release up by a day. A video from one of the reporting security firms, published by mistake, then sped up the appearance of proof-of-concept exploits, and one distributor published patched images more than six hours before the coordinated release.

timeline
    title How the PHP disclosure unfolded (UTC)
    Aug 11 2026 : Calif and OpenAI report the root cause
    Oct 20 3pm : CVE IDs leak online
    Oct 20 7.30pm : PHP publishes early pre-announcement
    Oct 21 7.41am : Chainguard ships fixed images early
    Oct 21 afternoon : PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 released

Source: PHP Foundation.

With exploits likely and the patch not yet out, agencies chose caution. The BBC reported that Finland temporarily shut down the government's public web services, the Netherlands' cyber-security agency took its own website offline, and listed Edinburgh council among the bodies that took pages offline. The Wikimedia Foundation said it had taken down a number of systems as a precaution, leaving some people unable to reach parts of Wikipedia. CNBC added that the Port of Rotterdam, the Dutch government portal Overheid.nl and several hospital websites also went offline, while France's Interior Ministry temporarily pulled local government administrative sites.

The warnings were unusually blunt. The UK's National Cyber Security Centre said that "where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated," the BBC reported, and the US National Security Agency issued similar advice. Cloudflare's chief technology officer, Dane Knecht, said the company was "seeing early attacks emerging" and called its firewall rules a "STOPGAP only."

How the bugs were found, and why it matters

This is also a story about how vulnerabilities are now discovered. The PHP Foundation says one of its developers first saw signs of the out-of-memory problem in 2024, after an external audit, but work on a fix stalled and restarted repeatedly over months because every option carried trade-offs. The Foundation called that delay "a structural failure."

The picture changed in August. Through OpenAI's Patch the Planet programme, security firm Calif began auditing PHP, and on 11 August researcher Ryan A reported an unconditional remote code execution with the same root cause; OpenAI independently reported it the same day, and Wiz followed with further attack vectors. Wiz told the BBC that "frontier models were critical to making this process practical," and described the flaws as the "most severe vulnerabilities ever discovered" by the technology.

The takeaway is uncomfortable for anyone who maintains software: AI-assisted research is finding deep bugs faster, for defenders and attackers alike. The PHP team says it has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. Lukasz Olejnik of King's College London told CNBC that "with AI exploitation may happen instantly, on a large scale."

What to do now

Only an update fully fixes these flaws. Based on guidance from CERT-EU, the NCSC and the PHP project:

1. Find every place PHP runs. As Sophos's Don Smith told the BBC, PHP can sit under websites, content management systems, hosting panels and third-party products without being obvious. CERT-EU points to the NCSC-NL php2shell repository for a list of products that embed PHP.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, preferably through your Linux distribution or LTS vendor, which received patches in advance. If you are on PHP 8.1 or older, upgrade or ask your vendor for a backport.
3. Do not assume WordPress auto-updates cover you. Wordfence warned that WordPress automatic updates would not apply this fix; the update has to happen in the server's PHP installation. On shared hosting, ask your provider when they patched.
4. If you cannot patch today, reduce exposure. CERT-EU lists temporary mitigations, such as disabling _INLINECODE0 and lowering INLINECODE1_, but stresses they do not make an installation safe. Taking a public site offline is a legitimate choice.
5. Check for signs of compromise. Because exploits circulated before many sites were patched, review logs and look for unexpected files or accounts.

The fix is out, and the sites that went dark on Wednesday were mostly acting out of caution, not because they had been breached. The risk now sits with the long tail: small sites on shared hosting and forgotten servers that nobody thinks of as "running PHP." If you own a website, today is the day to confirm who is responsible for its PHP version, and to get a clear answer.