PHP2Shell: how an old flaw in PHP became an emergency

On 21 October 2026 the PHP project shipped emergency releases for two flaws that let anyone on the internet run code on a web server running PHP, with no account and no password. Both are rated 9.2 under CVSS v4.0, the oldest affected code path dates to PHP 5.4.0 from 2012, and PHP runs on 69.3% of the websites whose server-side language is known, according to W3Techs ↗.

The flaws, CVE-2026-109618 and CVE-2026-109619, were found and proven with the help of AI models: by the research firm Calif, working inside OpenAI's Patch the Planet programme ↗, and independently by Wiz ↗. Details leaked a day before the fix. Amazon recorded what it describes as an exploitation attempt four days before the disclosure, and several European governments took public websites offline as a precaution while they patched. The researchers call the pair PHP2Shell.

This piece explains what broke, how a weakness first flagged in 2024 became an internet-wide emergency in 2026, what each source actually says about exploitation, who is exposed, and what to do today.

The 30‑second version

• →PHP fixed two critical flaws on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both allow remote code execution without logging in.
• →Every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the highest risk, because the attack completes before any application code runs.
• →The weakness is in PHP itself, so even a one-page "Hello World" script on an affected version is exposed. Researchers confirmed takeovers of WordPress, Drupal, Joomla, Magento, Laravel and six other applications.
• →A related bug was flagged in 2024, but its exploitation was unproven and the fix stalled for months. In 2026 researchers working with AI models proved remote code execution within days of starting.
• →Amazon saw an attempt on 17 October, four days before disclosure, and now calls the flaws "broadly exploited in the wild". CISA said on 21 October that it had not yet observed exploitation.
• →Upgrading is the only complete fix. PHP 8.1 and older get no official release, and CISA's advice is to take such systems offline until they are upgraded.

What broke inside PHP

Both flaws sit in how PHP cleans up when a request dies of a fatal error, most often running out of memory. PHP's security team published the technical detail in two advisories on GitHub; the summary below stays at that level.

CVE-2026-109618, "RCE via OOM corruption". When PHP hits its memory limit it abandons the work in progress at once. If that happens while some of its internal memory is reachable but still half-built, the clean-up at the end of the request reads that memory as if it were sound, the advisory ↗ explains, and an attacker who can shape it can turn the error into code execution. The memory pressure comes from the request body itself: PHP's parser for form fields and uploads can be made to use far more memory than the request takes up on the wire, so the application does not need to accept uploads for the path to be reachable.

CVE-2026-109619, "RCE via stale global state". A PHP worker process handles one request after another, and some of its shared state points into memory that belongs to a single request. A fatal error can cut a request short before that state is reset, and the next request on the same worker can reach the stale pointer before PHP initialises it again. That is a use-after-free: one request plants the condition and a later one triggers it. The advisory ↗ names confirmed triggers, including the session upload progress feature, which is on by default and runs without the application ever calling session_start().

How exposed a server is depends on how PHP is wired to the web server. With Apache's mod_php, PHP runs its request clean-up even when a request failed at startup, so the whole attack happens before any application code runs, and PHP rates that setup the highest risk. PHP-FPM, the usual setup behind nginx, discards a worker whose startup failed, which narrows the first flaw, but the PHP Foundation ↗ says code execution was also confirmed on FPM through application code paths, and the second flaw was validated against both. Because the weakness is in the runtime, Wiz notes that even a "Hello World" app on an affected version can be vulnerable.

Calif lists the applications on which it confirmed code execution without logging in; Wiz confirmed three of them independently, using the latest public container images.

Flagged in 2024, proven in 2026

The flaw comes from a long family. Calif's write-up ↗ traces it to 2004, when Stefan Esser, now at Calif, found the first remote vulnerability in PHP's memory limit. In 2020 a bug report, #78876, described long variable names in uploads exhausting memory. In 2024 PHP's first external security audit in years, funded through Germany's Sovereign Tech Agency, organised by OSTIF and carried out by Quarkslab, turned up a related bug, and Calif says PHP confirmed to it that exploitation was unproven at the time.

The PHP Foundation's own account adds that a core developer it had contracted found the out-of-memory root cause in 2024, and that the fix then stalled. The security team developed several competing approaches, each with a cost: broken backward compatibility, new denial-of-service risk, or changes to many third-party extensions. The team decides by consensus, so work on a fix would "stall and restart repeatedly over months". The Foundation calls the delay "a structural failure".

That changed in August 2026. Calif began auditing PHP on 30 July, found its first paths to remote code execution on 1 August, reported them on 11 August and sent PHP a working proof of concept on 14 August, which PHP confirmed the next day. OpenAI reported the same root cause on 11 August and added further attack paths on 18 September. Wiz, working separately, found its first bug on 19 August, confirmed unauthenticated code execution against Drupal and WordPress within two days and reported on 24 August. From 11 August the fix was the top priority of the Foundation's security team.

What the AI models did

Each finder describes the models' role differently, and the differences say more than the headline does.

• →Wiz used Wiz Atlas, its autonomous research system, with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol "throughout this research". It credits Gemini 4 Argon with help on finding the flaw, building the exploit, writing detections and checking the patch. Proving the bugs exploitable took a chain of steps "at the edge of what human researchers could practically achieve", Wiz writes; with the models, a single researcher finished in a week what it says would once have taken a world-class team months.
• →Calif says it used no special harness and no model beyond those generally available. Its researcher started from a theory that relatives of the 2004 memory-limit bug were still in the code. The models then helped find ways to trigger out-of-memory errors on demand, traced the root cause, and turned the first finding into a reusable pattern that surfaced the second. Its lesson is that knowing the target still counts: a model left to itself starts from the newest, best-known bugs, and a researcher who knows a codebase's history can point it at the old ones.
• →OpenAI credits Calif with finding a critical flaw using GPT-5.6 Sol and calls the pair "one of the most impactful security issues in recent memory". To its knowledge frontier AI found them before attackers did, and it expects similar findings "to increase sharply in the coming months".
• →The PHP Foundation says its security team has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicated or impossible to reproduce. AI tools help it sort them, but "a person makes every call and works on every patch".

Taken together, the models made it cheap to prove what a 2024 audit could only flag, and the proof is what turned a known weakness into an emergency release. The same capability serves whoever holds it. Amazon's threat report ↗ makes the point from the other side: AI-assisted analysis makes it cheaper to turn a published patch or advisory into a working exploit.

The last day before the patch

PHP planned to publish the fixes on 22 October. The PHP Foundation's timeline, with Amazon's and Cloudflare's, shows how that plan came apart in the final day (all times UTC):

• →20 October, about 15:00: the CVE numbers began circulating publicly.
• →19:30: PHP published a pre-announcement and moved the release a day earlier, to 21 October at 14:00.
• →About 20:00: Calif mistakenly published a video of its proof of concept, according to the Foundation.
• →About 23:00: mitigation advice sent to critical-infrastructure providers may have leaked as well.
• →21 October, about 02:00: Amazon saw several proof-of-concept exploits, and further attempts against its honeypots from anonymised infrastructure.
• →03:02: Cloudflare switched on protective firewall rules for every customer, free plans included.
• →07:41: Chainguard, a supplier of container images, published patched images more than six hours early; the Foundation says it "unilaterally broke the embargo".
• →14:00: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released.

One event sits outside that window. Amazon's honeypot network recorded an attempt on 17 October, from an address on a commercial anonymisation service, four days before disclosure. Amazon says it "remains unclear how the actor acquired exploit information". Its advice follows from that: hunt for signs of compromise starting on 17 October, the earliest known attempt.

Exploited? What each source says

Reports on exploitation disagree because they measure different things. A honeypot records attempts against a decoy; a confirmed compromise needs a real victim. As of 22 October:

No organisation had publicly confirmed a breach through PHP2Shell by 22 October. The attempts started before the fix existed, so the useful question for any team is whether its own servers were reached, and from when.

Who is exposed

Every PHP installation that serves web requests is in scope until it runs a fixed release. The official fixes cover the four supported branches, 8.2 to 8.5. For 7.4, 8.0 and 8.1, which are past end of life, PHP's security team published minimal source-code backports for anyone who builds PHP themselves, and Linux distributions and long-term support vendors received patches in advance. Releases older than 7.4 get nothing.

That matters because much of the web runs old PHP. From W3Techs' version shares on 22 October, we estimate that about half of PHP sites run a branch with an official fix, about a third run 7.4 to 8.1, where only the source backports exist, and about one in seven run something older.

Two groups are easy to miss. The first is PHP that sits beside the product: a marketing site on WordPress, a phpMyAdmin panel, Roundcube webmail, a WHMCS billing portal or a Nextcloud server, all on Calif's list of confirmed targets. The second is PHP inside container images and appliances, where the version on the host says nothing about the version in the image. OpenAI released a checker with the disclosure that identifies potentially vulnerable PHP versions; a version number alone cannot show that a patched build is the one running.

Operators took it seriously. Reuters reported ↗ that the Dutch National Cyber Security Centre took its own website offline as a precaution, and the Port of Rotterdam, the government portal Overheid.nl and several hospitals followed; Finland's state IT provider Valtori took public network services offline; France's Interior Ministry put its websites into maintenance; and Denmark's municipal IT company Kombit shut services including the national school communication platform. The UK's NCSC ↗ advised organisations to consider taking systems offline where they could not mitigate in time.

What to do now

The PHP project, CISA, the UK NCSC and the finders agree on the order of work.

• →Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker. A running worker keeps the old code in memory, so the fix takes effect only after a restart. Check container images, base images and bundled PHP as well as hosts.
• →On 8.1 or older, upgrade or take the system offline. CISA's advice ↗ for systems that cannot be updated straight away is to take them offline until they can be. The source backports for 7.4, 8.0 and 8.1 are an option for teams that build PHP from source.
• →Treat interim mitigations as time bought. PHP lists them with their limits: set session.upload_progress.enabled=0 in php.ini or the pool configuration and restart (ini_set() and .user.ini do not count); on PHP 8.5 set fatal_error_backtraces=0; set memory_limit=-1 in a way applications cannot override; cap request size, part count, header count and nesting depth at the web server or proxy, including requests without a usable Content-Length; and block multipart requests where the application takes no uploads. PHP warns against RLIMIT_AS and RLIMIT_DATA, which trigger the vulnerable path.
• →Use firewall rules as one layer. Cloudflare, AWS, Google Cloud and other providers shipped rules. AWS is explicit ↗ about their reach: they cut risk, and one of the two flaws sits largely outside what any web application firewall can see.
• →Hunt from 17 October. Look for POST requests carrying PHP_SESSION_UPLOAD_PROGRESS, unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses, unexplained worker churn, oversized PHPSESSID cookies, and PHP worker processes starting shells or downloading tools. Check for web shells, new cron jobs and new accounts. PHP's advisory adds that a clean error log proves nothing on its own.

What changes for a team that ships software

PHP2Shell is about one runtime, and nothing here claims what a particular tool would have caught. It does change five working assumptions.

• →The runtime is part of the product. The rule most web products depend on, "an unauthenticated request must never run code on our servers", broke on 21 October without a line of anyone's application code changing. An inventory of where PHP runs, side systems included, is the first control.
• →Unproven findings need an owner. The 2024 audit flagged a related bug, and without proof of exploitation the fix waited. Proof is what moved it to the top of the queue. A finding is a lead, exploitability takes proof, and models now make that proof cheap for defenders and attackers alike.
• →Patch clocks run in hours. Amazon's advice is to "measure patch and mitigation timelines in hours", because a 7-day or 30-day service level "assumes a delay that no longer exists".
• →Embargoes end early. This one gave way through a list of CVE numbers, a video, mitigation advice and an early image release. Plan on a fix arriving with little notice, and on exploit code arriving soon after it.
• →Re-prove after the patch. The upgrade is itself a change. Confirm that the patched build is the one serving traffic, that every worker has restarted, and that the rule holds again.

This is the loop ExploitOps describes: declare the rules a product has to hold, observe what changes, including the runtime under it, prove what is exploitable, fix it, and re-prove the rules after every change. The buyer's guide covers how to choose an audit, and the Record keeps PHP2Shell alongside the year's other AI security incidents.

Sources

• →PHP, Security advisory: Critical remote code execution vulnerabilities, update now ↗, 21 October 2026
• →PHP security advisories: RCE via OOM corruption, CVE-2026-109618 ↗ and RCE via stale global state, CVE-2026-109619 ↗, 21 October 2026
• →The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security ↗, 21 October 2026
• →Calif, php2shell: A tale of two PHP remote vulnerabilities ↗, October 2026
• →Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities ↗, 21 October 2026
• →OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities ↗, 21 October 2026
• →Amazon Threat Intelligence, PHP2Shell exploitation prior to public disclosure in MadPot ↗ and Using AWS WAF to apply mitigations ↗, 21 October 2026
• →CISA, Critical Vulnerabilities in PHP Require Immediate Patching ↗, 21 October 2026
• →UK NCSC, Critical security issue affecting PHP ↗, 21 October 2026
• →Cloudflare, Cloudflare deploys protections against php2shell vulnerability ↗, 21 October 2026
• →watchTowr, PHP Remote Code Execution FAQ ↗, updated 22 October 2026
• →Palo Alto Networks Unit 42, Threat Brief: Critical Vulnerabilities in PHP ↗, 21 October 2026
• →Reuters, via RTÉ, Websites go dark as AI exposes critical security flaws ↗, 21 October 2026
• →W3Techs, Usage statistics of PHP ↗ and PHP 8 versions ↗, 22 October 2026