PHP2Shell, Graded

At a glance

The flaws: CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell, each rated 9.2 of 10 (CVSS v4.0) by the PHP security team. Either can let an attacker with no account run code on a vulnerable web server. RECORD.
The fix: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, released October 21, 2026. Updating is the only complete fix, and the PHP project ships no fixed release for PHP 8.1 or older. RECORD.
The federal clock: CISA placed both flaws on its Known Exploited Vulnerabilities catalog on October 26, 2026. Federal civilian agencies must remediate by October 29, 2026. RECORD.
The honest count: no government has published a total of affected or compromised systems, and no source quantifies people affected. UNKNOWN, and treated below as a finding, not a gap.

What the two flaws are

Both flaws are memory-handling bugs inside PHP itself. They are not in WordPress, Drupal, Joomla, or any plugin, and updating those applications does not close them.

The first flaw (CVE-2026-109618) sits in how PHP handles running out of memory in the middle of a request. The request's data can be left partly built, and the cleanup that follows treats that broken data as if it were sound. The second flaw (CVE-2026-109619) leaves internal state from one request pointing at memory that has already been freed, so the next request handled by the same worker can pick up the stale state before it is reset. Worked through, either path can give an unauthenticated attacker control of code running on the server. The same weaknesses can also let an attacker read memory out of the PHP worker process, and that memory can hold passwords, authentication tokens, API keys, and certificates belonging to other requests or to the server itself. RECORD: PHP security advisory, October 21, 2026; Wiz Research technical write-up.

The vulnerable code dates back to PHP 5.4, released in 2012. The weaknesses had been noticed in some form about two years ago and were judged at the time to have no practical exploitation path, so they stayed in place. This year, researchers at Wiz Research and at the security firm Calif, working with AI models, found the path. Wiz reported the flaws privately to the PHP project on August 24, 2026, and the fix was prepared over about two months. Disclosure was planned for October 22; the CVE numbers circulated early and details leaked, so PHP shipped the fixed versions a day early, on October 21. RECORD: Wiz Research; the PHP Foundation's account as reported by TechCrunch.

PHP states that every installation serving web requests is at risk, across PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is highest on Apache with mod_php, where PHP states a demonstrated attack runs from a single request before any application code executes. Wiz demonstrated the attack against stock WordPress, Drupal, and Joomla, and notes that a trivial test page on an affected version is as exposed as a full application. PHP runs on roughly 70 percent of websites whose server-side technology is known. RECORD: PHP advisory; Wiz Research; usage share per W3Techs.

A separate third flaw in the same neighborhood, CVE-2026-115560, was disclosed on October 23. It is not part of PHP2Shell, it needs an unusual session configuration, and PHP advises turning off session upload progress until its fix ships in the next regular release. It is named here only so readers do not merge it into the pair. RECORD: PHP informational advisory.

The week, in order

October 17. Amazon Threat Intelligence records the first exploitation attempt it can see, four days before anyone has published anything. Amazon says it is unclear whether the early attempts would have succeeded. RECORD: AWS.

October 21. PHP ships the fixed versions. CISA issues its alert, "Critical Vulnerabilities in PHP Require Immediate Patching," urging every organization to inventory its PHP, update at once, and take systems offline if they cannot be updated or run PHP 8.1 or earlier. At that moment CISA states it has not observed exploitation. The National Security Agency issues a rare public warning to the same effect: patch immediately, or take the system offline. Cloudflare turns on firewall rules for the known attack paths, including for its free-plan customers. RECORD: CISA; NSA as reported by the BBC; Cloudflare.

October 21, within hours. Exploitation attempts climb from tens of thousands in the first 45 minutes to hundreds of thousands in two hours, and to millions by October 22 on Cloudflare's network alone. Attackers adjust their payloads to work around the new firewall rules. Attempts are probes and attacks in flight; they are not, by themselves, break-ins. RECORD: Cloudflare.

October 24. A security researcher records 35 successful shell executions across three honeypots running an unpatched PHP version under Apache mod_php. The honeypots were configured in a way that favors the attacker, and the researcher says so; the result proves the attack works end to end, not how often it works in production. Separately, one widely carried claim of a break-in at a European government agency is later withdrawn by the firm that made it, which states it cannot confirm these flaws were the way in. That retraction is part of the record, and it is printed here for the same reason the claim was news. RECORD: the researcher's published honeypot report; Palo Alto Networks Unit 42 correction, October 25. Sophos likewise walked its early assessment back to scanning and failed attempts.

October 26. CISA places both flaws on the Known Exploited Vulnerabilities catalog, confirming that it now considers both actively exploited, with the federal deadline set for October 29. The catalog entries list use in ransomware campaigns as "Unknown" and require forensic triage. CISA does not name any compromised organization. RECORD: CISA KEV catalog.

The government picture

The established United States impact, as of October 27, is a deadline, not a damage report. Every federal civilian agency running PHP on a reachable system had three days from the catalog listing to patch or to take the system offline, under Binding Operational Directive 22-01. CISA urges organizations outside the federal government to treat the same date as their own. No US agency has published a count of its affected systems, CISA has published no federal total, and no confirmed compromise of a US government system has been publicly established in the sources for this piece. UNKNOWN, stated plainly: the size of the US federal footprint for these flaws is not publicly quantified.

Outside the United States, the visible government impact was self-inflicted on purpose, and the distinction matters. In the days around the patch, governments in Germany, France, Belgium, the Netherlands, Finland, and the Czech Republic took public websites offline as a precaution while their teams applied the fix. France's Interior Ministry switched off the sites of its local administrative offices. In the Netherlands the shutdowns reached the services citizens actually use: the national digital identity system DigiD, the citizen portal MijnOverheid, the central government portal, the House of Representatives site, and the Dutch cyber security centre's own website. In the United Kingdom, the Office for Budget Responsibility and several councils, including Oxfordshire, Hillingdon, and Edinburgh, took sites down, as did a number of Scottish councils and health boards. The Wikimedia Foundation took systems down as a precaution; Wikipedia runs on PHP. In Australia, the tax office, the health department, and the communications regulator were reported limited during mitigation, and the national cyber.gov.au site was among those hit by outage. South Africa's Presidency site stayed offline as a precaution, with its spokesperson telling Reuters there was no indication of a breach. Japan's Prime Minister told the public to check whether their sites ran PHP and said taking a site down temporarily was a legitimate way to reduce risk while patching. REPORTED: Al Jazeera, the BBC, Sky News, Reuters, and AAP coverage, October 21 to 24. In every one of these reports, the shutdown was the owner's choice, made to patch safely. None of them establishes that the site in question was breached.

That is the correct shape of the government story so far: a great many public systems were deliberately dark for hours so that a three-day federal clock and its equivalents abroad could be met, and the public record does not yet contain a confirmed government compromise to set against that effort.

The systems picture

Websites are the visible layer. PHP is also a component bundled inside other products, where the operator may not know it is there, and CISA's first instruction in its alert is an inventory for exactly that reason.

One vendor has confirmed its products in the open. Palo Alto Networks states that the flaws affect the management interfaces of its PAN-OS firewall software and its Panorama management platform, across the 12.2, 12.1, 11.2, 11.1, and 10.2 trains below fixed hotfix builds. It rates the impact on its products at 8.7, assesses the impact as availability, began shipping hotfixes on October 26 with the rest due by October 30, and states it is not aware of exploitation against its products. Some of its cloud services were affected and were remediated on October 21 and 22; others are listed as unaffected. RECORD: Palo Alto Networks advisory. As of October 22, Fortinet was still checking 12 of its products and Cisco 31 products and cloud services, and neither had confirmed a vulnerable product at that time. REPORTED: Help Net Security. Britain's National Cyber Security Centre advises organizations to keep watching their third-party vendors for updates even after PHP itself is patched, because the bundled copies patch on the vendor's schedule, not PHP's.

The practical consequence for any organization, public or private: updating the web servers you know about is the first pass, not the whole job. The appliances, hosting panels, and bundled products are the second pass, and they close on someone else's calendar.

The numbers that exist, and the ones that do not

Numbers exist for attacker activity. Cloudflare counted attempts in the millions by October 22. A university threat intelligence lab in Delft tracked more than 50,000 exploitation requests from over 600 addresses in 70 countries, with 171 of those addresses going on to send exploit code or malware droppers. A threat intelligence firm reports watching one operator group, which it links to North Korea, working slowly and deliberately from 21 compromised machines, checking a list of 216 hosts that still looked unpatched or partly protected on October 24. REPORTED: TU Delft figures via The Register; Cyfirma via SecurityAffairs.

Numbers exist, with limits, for patching speed. A free public checker that site owners ran against their own sites found that, among sites whose PHP version could be read, 59 percent still showed a version from before the fix across checks run October 21 to 25, and that the patched share of each day's first checks rose from 21 percent on October 21 to 50 percent on October 25. The checker's own stated limits ride with those figures: owners chose what to check, most sites hide their version, and a hidden version is not a safe version. Danish industry reporting counted more than 21,000 Danish websites still without the update on October 24. REPORTED: Brandefense checker aggregate; Danish industry reporting.

The numbers that do not exist are the ones being asked for most. There is no published count of compromised systems, from any government or vendor, as of October 27. There is no published count of people affected, because there is no publicly established breach with personal data loss to count people from. Research attributed to Deloitte Tohmatsu Cyber and W3Techs puts 48 percent of PHP-using sites on versions that no longer receive official security updates at all, which describes the size of the long tail, not a count of the affected. Anyone who gives you a precise number of victims for PHP2Shell today is estimating, and the estimate is not labeled as one in most of the places it appears. UNKNOWN, and it stays unknown on this page until a source of record publishes it.

If you run PHP

The sequence below is CISA's and the PHP project's, in order. It is written for whoever owns the servers, including the ones nobody remembers.

1. Inventory first. Find every PHP installation, including PHP bundled inside appliances, hosting panels, and third-party products. Assume the list you have is incomplete.
2. Update to the fixed release for your branch: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Check the version the web server actually loads, not only the command-line version. Internet-facing systems first, Apache with mod_php before anything else.
3. If a system runs PHP 8.1 or older, or cannot be updated now, take it offline until it can be updated or moved to a vendor build that carries the fix. There is no fixed release from the PHP project for those branches.
4. Ask every vendor of an appliance or hosted product that bundles PHP for its fixed version and its date, and write the answer down. Palo Alto's hotfix schedule runs to October 30; other vendors are on their own dates.
5. Check the exposed window. Exploitation attempts predate the patch. For any server that was reachable and unpatched on or after October 24, look for web shells, new PHP files in web roots, and new scheduled jobs before calling the work done. The catalog listing requires forensic triage for federal systems; the same check is the honest standard for everyone else.
6. Watch the workers. Until every instance is updated, monitor for PHP worker processes launching shells or downloading tools, and keep firewall management interfaces reachable only from trusted addresses.

Rollback note, printed because this desk prints one wherever a step changes state: an update that breaks a site rolls back to the previous PHP build only behind a firewall rule or an offline state, never back onto the open internet unpatched. The vulnerable version is not a safe fallback; it is the exposure.

Verdict and mitigation

VERDICT. The exposure is real, confirmed exploited, and engine-deep: it reaches every product built on PHP, including products whose owners do not know PHP is inside them. The harm, by contrast, is not yet publicly counted anywhere, and the loudest early claims of specific compromises have been partly withdrawn by the firms that made them. Both halves of that sentence are the record as of October 27, 2026.

MITIGATION. Patch on the federal clock whether or not the clock binds you, inventory past the servers you know about, and check the pre-patch window for planted files. Treat any precise victim count, from any source, as unverified until an agency or a vendor publishes one it will stand behind.

Our posture

Our estate does not use the affected component; exposure none. The work above is offered because our readers' houses are built differently, and the clock on theirs is real.

Sources

CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," October 21, 2026, and the CISA Known Exploited Vulnerabilities catalog entries for CVE-2026-109618 and CVE-2026-109619, added October 26, 2026 · PHP security advisory and release notes, October 21, 2026 · Wiz Research, PHP2Shell technical write-up · AWS Security Blog, via The Register · Cloudflare, via SecurityAffairs and Reuters · The Register, October 27, 2026 · TechCrunch, October 27, 2026 · Palo Alto Networks security advisory, as updated October 26, 2026, and Unit 42 correction of October 25, 2026 · Brandefense, PHP2Shell checker aggregate, October 21 to 25, 2026 · TU Delft Threat Intelligence Lab figures, via The Register · Al Jazeera, BBC, Sky News, and AAP reporting, October 21 to 24, 2026.

Version history. October 27, 2026: Initial version.