PHP2Shell Patch Bypass Claim Another RCE on PHP 8.5.12

A day after PHP shipped the emergency fix for PHP2Shell, a researcher published proof-of-concept code claiming remote code execution against a fully patched PHP 8.5.12, the version released on 21 October 2026 to close CVE-2026-109618 and CVE-2026-109619.

The release, posted to GitHub by a researcher using the handle rafalohaki, was posted on X on 22 October, describes a “pure logic bug” that the author says is separate from the two memory-corruption flaws the patch addressed, with a demo showing a one-shot HTTP request returning a shell as uid=33(www-data) on Debian 13.

The claim lands in the middle of the largest PHP security scramble in years, but it is narrower than the headline suggests, and the researcher says so plainly. The repository states the technique against 8.5.12 depends on “session gaps” and specific conditions, and a second chain, it demonstrates — session-file poisoning to local file inclusion to RCE on PHP 8.5.11 — is described by its own author as “an application flaw, not a PHP core bug.”

What the new PoC actually does

The original PHP2Shell bugs sit in the PHP engine itself, so any site running a vulnerable interpreter is exposed regardless of its own code. The patch bypass that is being circulated is a different kind of thing.

According to the repository, the 8.5.12 exploit abuses the way PHP handles session state between requests — poisoning a session key that persists in a session file, then triggering it through a handler that processes PHP — rather than the out-of-memory corruption (CVE-2026-109618) or stale global state (CVE-2026-109619) that the official release fixed.

According to the repo, the list of conditions the target has to meet includes several sinks that do not work: a session ID containing .php is rejected because PHP validates the session id, php://input via include fails because allow_url_include is off by default and deprecated in PHP 8, and error-log poisoning fails because PHP HTML-encodes the payload.

The author frames the work as research over public PHP code and a demonstration of specific, conditional chains, not a drop-in exploit that turns every 8.5.12 server into a shell. As of 22 October 2026, the claim had not been independently reproduced or confirmed by the PHP security team, and PHP has not issued a further advisory in response.

A working bypass of the official fix for a bug this widespread would be severe; a conditional, configuration-dependent chain and a separate application-level LFI are serious but far smaller in blast radius. Both descriptions have been circulating under the same “patched PHP still vulnerable” framing, and only the first would justify the alarm.

Attackers were already probing before anyone knew

The bypass claim arrives on top of evidence that exploitation of PHP2Shell began before the public ever heard the name. Amazon’s threat-intelligence team reported on 21 October that its MadPot honeypot network recorded a PHP2Shell exploitation attempt on 17 October, four days before disclosure, from an IP address tied to a commercial anonymisation network.

“The exploit attempt originated from an IP address associated with a commercial anonymization network,” wrote CJ Moses, CISO of Amazon Integrated Security, who added that it is unclear how the actor obtained exploit details while the flaw was still under embargo.

In the hours around the 14:00 UTC embargo lift, it saw multiple proof-of-concept exploits — the earliest around 02:00 UTC — and attempts from varied infrastructure and payloads that suggested several actors, not one. The company argues the gap between patch and working exploit is collapsing because AI-assisted analysis makes turning a patch diff or advisory into an exploit cheaper, so defenders should measure patching for critical internet-facing bugs in hours, not days, and investigate from the earliest known exploitation date rather than the disclosure date. For PHP2Shell, Amazon says, that means starting from at least 17 October.

Cloudflare’s chief executive, Matthew Prince, said on X that attackers had made millions of exploitation attempts since disclosure, and the company’s CTO, Dane Knecht, said Cloudflare watched attackers change payloads to slip past its first mitigation rules. Even so, officials in Germany, the Netherlands and Japan have said none of the attempts appears to have succeeded. “At the moment it doesn’t look like exploitation has taken off or been widespread,” Ryan Austin, a Calif researcher who helped find the flaws, told the Guardian.

Where the panic outran the facts

The PHP2Shell story has also generated claims that do not hold up against the primary sources. Posts on X this week described an internet “lockdown,” a coordinated wave of government, bank and hospital shutdowns, and a wave of breaches branded “Black October.”

The precautionary shutdowns were real and widespread — Dutch and Finnish government services, French prefecture sites, several German state and city portals, and banks and airlines in Japan and Nepal all took systems offline as a precaution while they patched — but they were preventive, not the result of confirmed compromise. No successful break-in has been publicly confirmed.

The same gap between rumor and record shaped the disclosure itself. The flaws leaked a day early after an anonymous Hacker News post citing a trusted tip went up and came down on 20 October, screenshots of a leaked exploit tool credited to Calif spread to X and Mastodon, and Calif itself briefly posted a proof-of-concept video.

In the rush, a single php.ini setting — disabling session upload progress — circulated as the fix; GMO Flatt Security, which suggested it, later said it was not enough on its own, and PHP’s own advisory is blunt that there is no complete mitigation short of updating.

OpenAI, which helped discover the original flaws under its Patch the Planet program and called them “one of the most impactful security issues in recent memory,” has published a checker as two Codex skills that test whether a URL or a local PHP binary is on a vulnerable version. Its documentation carries a warning worth repeating in light of the bypass claims: an “UNKNOWN” result does not mean the target is patched.”

What to do

Nothing in the bypass claim changes the baseline advice, and the fix for the core flaws remains the priority. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package, then restart PHP-FPM, Apache and any long-running workers so the old code stops serving requests.

Branches 8.1 and older get no release from php.net, so those still on 8.1, 8.0 or 7.4 need a vendor or source backport as a bridge and a plan to move to a supported branch. On the new PoC specifically, the mitigations that reduce exposure — keeping allow_url_include off, letting PHP validate session IDs, and auditing application code that includes files built from user-controlled input — are standard hardening already in place on most correctly configured servers.

The researcher behind the bypass has not released a universal exploit, PHP has not confirmed the claim, and no breach using it has been reported. What the past 48 hours have established is narrower and more durable than any single PoC: with the core advisories now public and exploit development accelerating, the window between a PHP patch and a working attack against the servers that ignore it is measured in hours.