PHP, the programming language behind WordPress, Drupal, Joomla and Magento sites, shipped emergency security fixes on 21 October 2026 for two critical flaws that let an attacker run code of their choosing on a vulnerable server without logging in. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, both carry a CVSS v4.0 score of 9.2. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The reason this flaw drew warnings from government cyber agencies within hours is scope. PHP runs on almost 70 percent of websites, according to W3Techs figures cited by Cloudflare. That figure is PHP’s share of the web, not a count of sites currently at risk: a site running a patched version is not exposed by these flaws. Every PHP version released in the last decade is affected by at least one of the two flaws, according to Wiz Research, with the vulnerable code pattern going back to version 5.4, released in 2012 and unsupported for years. That describes how far back the affected code reaches, not that PHP 5.4 itself is still supported. Wiz demonstrated unauthenticated remote code execution on WordPress, Drupal and Joomla deployments, plus unauthenticated disclosure of PHP worker memory containing passwords, tokens and API keys.
Update, 22 October: attacks began before disclosure, investigators told to look back to 17 October
Amazon Threat Intelligence found a PHP2Shell exploitation attempt dated 17 October 2026 in its MadPot honeypot telemetry, four days before public disclosure, according to Amazon and reported by The Register on 22 October. The attempt came via a commercial anonymisation network. Amazon says it is unclear how the actor obtained exploit information while it was under embargo, and unclear whether the attempt would have worked against a real system. MadPot is a honeypot network, not a production system, so this is not a confirmed compromise of a real site.
For site owners, the practical change is the look-back window: check logs back to at least 17 October, following Amazon’s advice, rather than starting from the 21 October disclosure.
Cloudflare’s escalation curve, given by chief executive Matthew Prince via The Register, shows thousands of attempts in the 10 hours before announcement, tens of thousands within 45 minutes of disclosure, hundreds of thousands within two hours, and millions since. Those figures count attempts, not confirmed successful breaches.
The disclosure itself produced a blame row. Chainguard published built images with the fix at 07:41 UTC on 21 October, over six hours before the coordinated 14:00 UTC release. The PHP Foundation accused Chainguard of breaking the embargo. Chainguard chief executive Dan Lorenc does not dispute the timeline, says the company “didn’t leak”, and says he shipped because “people were getting hit in advance”.
Amazon says PHP2Shell is now being broadly exploited in the wild after patches shipped. That claim needs its counter-nuance in the same breath: WatchTowr told SecurityWeek the circulating proof-of-concept exploits “either don’t work at all, test for timing-based differences, or crash the target”.
What PHP2Shell actually is
PHP2Shell is the name researchers gave to the pair of flaws. PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest demonstrated risk for mod_php. Beyond remote code execution, the flaws can also cause denial of service and data exposure.
PHP had warned a day earlier, on 20 October, that the security release was scheduled for 21 October at 14:00 UTC (19:30 IST), covering two critical vulnerabilities, and reserved the right to release earlier if details became public or evidence of active exploitation appeared. The release landed on schedule.
There is one important limit to the patches. PHP 8.1 and older no longer receive regular updates from the PHP project itself. PHP provided only minimal source backports for PHP 7.4, 8.0 and 8.1 to help people building from source or without a long-term-support vendor, and says distribution and LTS vendors should be checked for backported packages. If your site runs PHP 8.1 or older, updating the PHP package alone may not be enough; check with your host or vendor for a backported fix.
Why websites went dark yesterday
On 21 October, websites across Europe went offline, but the shutdowns were precautionary, not confirmed breaches, according to Reuters’ Wednesday account. France’s Interior Ministry temporarily took prefecture websites offline pending a PHP fix. Germany’s federal IT provider ITZBund took several websites offline, purely preventive, with no security incidents known, according to Reuters. Belgium’s foreign ministry took its websites offline, following reports of cyberattacks exploiting the PHP vulnerabilities, although the country’s cybersecurity centre said it had not recorded any attacks on Belgian websites. In the Netherlands, many organisations followed the National Cyber Security Centre’s example, including the Port of Rotterdam, the government site Overheid.nl, football association KNVB, the five largest political parties’ websites and numerous hospital websites. Finland’s state IT centre Valtori shut down government public web services as a precaution and said it had not identified any exploitation attempt and the outage was not the result of a data breach. The Wikimedia Foundation said all foundation-supported and volunteer-run systems using PHP are affected and it had taken down a number of other systems as a precaution until safely patched. In the US, the forum Something Awful temporarily shut its message boards, according to the New York Post.
The exploitation picture needs its sequence stated plainly, because the statements came at different times. Before the patches, in Reuters’ pre-patch coverage on 21 October, Australia’s Cyber Security Centre said it was “currently not aware of active exploitation related to these vulnerabilities.” Cloudflare, which turned on WAF protection for php2shell by default for free and paid WAF customers from 03:02 UTC on 21 October, said it observed attack traffic targeting its customers and attackers mutating payloads to try to bypass protections. After the patches, at 15:26 UTC (20:56 IST), Krebs on Security reported working exploits and that the flaws were already being exploited in the wild, and watchTowr said it was observing active exploitation attempts of both CVEs. These statements are not all measuring the same thing: an agency saying it is not aware of exploitation is not the same as no exploitation happening, and attack traffic is not the same as confirmed breaches. No named compromised website or organisation and no confirmed consumer victim count had been published, and the New York Post noted that widespread successful breaches had not been confirmed.
OpenAI’s role was coordination: before disclosure, Wiz worked with the PHP team, Calif and OpenAI to measure the size of the problem and coordinate patch verification and disclosure, according to Wiz via Krebs on Security. OpenAI said, in a quote carried by Krebs on Security, that given the severity of these flaws and PHP’s widespread use, it considers this one of the most impactful security issues in recent memory. That assessment is OpenAI’s opinion, not a measured outcome. Wiz has compared PHP2Shell with Log4Shell from 2021; that comparison is Wiz’s assessment, not a measured outcome.
What should I do if my site runs PHP?
If your website runs on PHP, update PHP to a fixed version now, or get your hosting provider to do it. Patching is the only complete solution, according to PHP, and there are no complete mitigations. The steps below cover the update itself, the hosting check, and protection while you patch.
- Check your PHP version in your hosting control panel, or ask your hosting provider to confirm it for you.
- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, whichever version line your site currently runs on.
- Ask your host to confirm the update if your site is managed or shared hosting.
- Keep Cloudflare WAF protection enabled while you patch, if your site sits behind Cloudflare’s proxy service.
- Verify your site still loads fully after the update, including contact forms, login pages and checkout pages.
- Consider taking the site offline temporarily if patching immediately is impossible, following CERT-EU’s precautionary advice.
WordPress site owners should treat this with the same urgency as any WordPress security incident. Our earlier coverage of the UpdraftCentral key compromise showed how quickly a WordPress ecosystem flaw turns into live backdoors, and the Rank Math PRO supply-chain attack showed why update channels themselves deserve attention. Neither of those incidents is connected to PHP2Shell; the point is only that patching fast is what separates a scare from a compromise.
The timeline that matters: our reconstruction
TechReview analysis: the sequence below is our own ordering of the dated sources cited in this article, not copied from any single source. On 20 October, PHP gave advance notice of a 21 October 14:00 UTC release. At 03:02 UTC on 21 October, Cloudflare’s WAF protection switched on by default, with attack traffic already observed. Before the 14:00 UTC patch, Australia’s Cyber Security Centre said it was not aware of active exploitation, in Reuters’ pre-patch coverage. At 14:00 UTC (19:30 IST), PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35. At 15:26 UTC (20:56 IST), Krebs on Security warned that many sites may serve errors, while reporting working exploits and in-the-wild exploitation. The gap that matters for readers is the window between disclosure and your own patch: protections and patches landed hours apart, but a site stays exposed until it is patched, even after the fix exists.
TechReview analysis: adding two Shodan counts cited by SOCRadar gives a sense of the exposure, not of victims. There are 884,000 internet-facing hosts running PHP 8.1 or older, plus 740,000 hosts running PHP without a specified version, which adds up to 1,624,000 hosts in those two buckets alone. That is our addition of Shodan counts cited by SOCRadar. It is not a count of confirmed vulnerable or compromised hosts, and the 8.1-or-older bucket includes versions that may receive distribution backports.
What to watch next
Three things are still unconfirmed and worth watching. First, whether any named organisation confirms a real compromise, as opposed to precautionary shutdowns or blocked attack traffic. Second, whether either CVE appears in CISA’s Known Exploited Vulnerabilities catalog; checked 22 October, neither is listed in the catalog (version 2026.10.21). Third, whether the shutdowns in Europe reverse quickly now that patches are out, which would confirm they were precautionary. Until a named compromise appears, do not assume your personal data was stolen from any site because of PHP2Shell; no confirmed consumer data theft from a named site is established.
Sources: PHP security advisory and news archive, 20-21 Oct 2026; Cloudflare Blog, 21 Oct 2026; Wiz Research, 21 Oct 2026; Krebs on Security, 21 Oct 2026; Reuters, 21 Oct 2026 (pre-patch warning including the ACSC statement, and Wednesday follow-up on the precautionary shutdowns); New York Post, 21 Oct 2026 (Something Awful shutdown; no widespread successful breaches confirmed); SOCRadar summary of vendor claims, 21 Oct 2026; CISA Known Exploited Vulnerabilities catalog, checked 22 Oct 2026. Amazon Threat Intelligence / AWS Security Blog, 21 Oct 2026 (MadPot finding); The Register, 22 Oct 2026 (AWS revelation and escalation curve; Chainguard disclosure row); SecurityWeek, 22 Oct 2026 (WatchTowr proof-of-concept assessment).
