Two critical PHP vulnerabilities triggered a broad security response on Oct. 21, with governments, hosting providers, and security teams rushing to contain the fallout from bugs that affect one of the web’s most widely used server-side technologies.
According to W3Techs, PHP powers about 70% of websites whose server-side language is known. That reach turned the disclosure into a global operational problem within hours. Finland began taking government web services offline on Wednesday, the U.S. National Security Agency recommended that organizations using PHP shut down their sites, and authorities in the Netherlands and France took similar steps. The incident was not tied to cyberwar, the report said.
PHP itself was the source of the problem. Many users may never notice it directly, but it sits behind a large share of the modern web. WordPress security firm Wordfence said every WordPress site runs on a PHP server. At the time of the report, Wordfence itself was also down.
The two newly disclosed flaws allow unauthenticated remote code execution. In practice, that means an outside attacker can run commands on a vulnerable server without logging in first. GoDaddy warned the bugs could be used to steal data, deface websites, or fully take over servers. In its words, 「A flaw like this could let an attacker run their own code on an affected server over the internet, which can lead to stolen data, a defaced site, or a full takeover,」 Godaddy says.
PHP Foundation warning and patch release
The PHP Foundation, the nonprofit that funds development of the language, issued an alert on Tuesday. In a statement posted on X, it said: 「The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.」
The 9.2 score comes from the Common Vulnerability Scoring System, which rates software flaws on a 0 to 10 scale. Anything from 9.0 upward is classified as critical.
The fix arrived slightly ahead of schedule at about 13:35 UTC on Wednesday in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The advisory was direct: 「All PHP users are strongly encouraged to update immediately.」 Even so, the report noted that publishing a fix and getting it deployed across the internet are two different things.
How the vulnerabilities work
The first flaw, CVE-2026-109618, appears when PHP runs out of memory in the middle of handling a request and later treats partially built data as if it were complete. The second, CVE-2026-109619, involves request data that should have been discarded but remains in memory long enough for a later request to interact with it.
The report compared the behavior to a cook reading order slips that were already thrown in the trash. If someone slips in a fake ticket, the cook prepares whatever is written on it. Here, the fake order is attacker-controlled code, and the server executes it.
PHP said the highest risk is on servers using mod_php, a common Apache setup. In that environment, a demonstrated exploit works 「before any application code runs.」 That means site-level defenses such as login screens or WordPress security plugins do not get a chance to intervene.
Researchers tied to the PHP Foundation also pointed to PHP’s upload-progress feature as one confirmed entry path. The feature tracks file upload progress, has been enabled by default for more than a decade, and is rarely used by websites in practice.
Leak, embargo, and early attack activity
The disclosure was not supposed to become public that early. On Tuesday, a post on Hacker News claimed that two PHP flaws would be disclosed on Thursday, while admitting there was 「no evidence beyond 'source: trust me, bro.'」 The claim turned out to be accurate. Security firm watchTowr confirmed the bugs were real and under embargo, and PHP moved the release forward by one day.
Cloudflare CTO Dane Knecht wrote on X early Wednesday, nearly six hours before the patch shipped: 「We are seeing early attacks emerging and are updating mitigations as new vectors show up.」 Cloudflare pushed emergency firewall rules to all customers to block known exploit patterns, but Knecht described them as 「a stopgap only.」
He also said PHP sites behind Cloudflare already had an initial set of WAF rules deployed for the known exploit vectors and that the rules were available to all customers, including free users.
Government agencies pulled sites offline
Finland’s state IT center Valtori began taking public web services offline as a precaution, according to public broadcaster Yle. The Dutch national cybersecurity agency took down its own website.
France’s Interior Ministry said prefecture websites were 「temporarily taken offline pending the release of a security patch by the framework's publisher.」
CERT-EU, the European Union’s cyber emergency team, told organizations that could not patch immediately to 「consider isolating internet-facing applications from public networks until a fix is available.」 The report said that was effectively a call to unplug exposed systems. Reuters reported that agencies in Australia, Japan, and the U.K. issued similar guidance.
What social media got wrong
Viral posts on X claimed vulnerable PHP versions dated back to 2004. The report traced that claim to early estimates suggesting everything since PHP 5 was affected, an assessment that CERT-EU said was based on social media posts.
E-commerce security firm Sansec placed the affected range at PHP 5.4 and later, which points to 2012 rather than 2004. That still covers a long span of legacy deployments.
PHP officially ships releases only for version 8.2 and newer, so claims that older versions had no fix were only partly correct. Because of the severity of the issue, the security team also published minimal source-code patches for 7.4, 8.0, and 8.1, while Linux distributions began backporting their own fixes.
Security firm Mallory counted about 884,000 internet-facing hosts advertising PHP 8.1 or older on Oct. 20. That represented 59% of roughly 1.5 million hosts publicly showing a version. The report added that a single shared-hosting server can support many websites, so the number of affected sites is likely higher.
Some online threads also folded Node.js into the same incident. The report said that was incorrect: Node.js had its own unrelated security update scheduled for the same day.
The PHP Foundation also warned users relying on the volunteer-maintained repository rpms.remirepo.net to move to distribution packages or build from source immediately, because 「The repo will not have updates today.」 The repository is a common PHP package source for Red Hat-style Linux servers.
Why regular users, including crypto users, should pay attention
The report said there is no reason for average users to panic, but also no reason to dismiss the issue. A compromised website does not need to touch a blockchain directly to drain a wallet.
It pointed to 2024 attacks in which the front ends of DeFi protocols Compound and Celer were redirected to wallet-draining pages, and to a similar incident involving Curve Finance in 2025. Those were DNS hijacks rather than PHP exploits, but the user-facing trick was similar: the page looked legitimate, the URL looked legitimate, and the approval button sent tokens elsewhere. A compromised server could serve the same kind of page.
The report also said zero-day discovery is becoming easier as frontier AI models are increasingly used to find software vulnerabilities. Experts cited by Decrypt in June said more vulnerabilities could surface as those tools spread.
What comes next
Once a patch is public, attackers can compare old and new code to identify exactly what changed. Sansec’s forensics team said it expects 「mass attacks to start within 15 minutes of the release.」 The report added that when a different PHP flaw became public in June 2024, Akamai saw exploit attempts against its decoy servers within 24 hours.
For ordinary users, phones, browsers, and laptops do not need a PHP patch. The burden falls on the operators of the websites they use.
For site owners, the report said they should ask hosting providers whether PHP has been updated and should not assume WordPress will handle it automatically. Wordfence warned that automatic updates will not apply this fix and told site owners to determine who is responsible for updating PHP on their servers. Anyone still on 8.1 or older needs to plan an upgrade.
PHP core developer Gina Peter Banyard wrote on Mastodon: 「The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.」
Users on PHP 8.2 are also nearing the end of that branch’s support window. According to the report, PHP 8.2 reaches end of life on Dec. 31, 2026, after which it will no longer receive security patches.