PHP2Shell patches land for two bugs that hand attackers the web server

Key points - The PHP project has released emergency fixes for two critical flaws, together nicknamed PHP2Shell, that sit inside the PHP runtime rather than in any website's own code. - The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the maintainers say only a full update closes the hole. - The first flaw abuses out-of-memory errors during file upload parsing; the second abuses stale data left behind in a worker process between requests. - Both can lead to remote code execution, meaning a stranger on the internet can run their own commands on the web server. - An estimated three quarters of websites run PHP somewhere in their stack, so the exposure is wide even if most sites will never be targeted directly.

The PHP project has pushed out emergency patches for two serious bugs in the language itself. In the engine that runs WordPress, Laravel, and everything else built on PHP. Not in any app sitting on top.

The pair have been nicknamed PHP2Shell, and together they let an attacker with no account on a site run their own code on the web server behind it. That's the worst class of web bug there is.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Partial mitigations don't cut it. Update, or stay exposed.

How do the bugs actually work?

Both bugs abuse the moment PHP runs out of memory while handling a request. Think of it as the server tripping over its own feet mid-sentence and leaving half-written notes on the desk for the next visitor to read.

An attacker can send a specially shaped upload that slips past PHP's own size limits but forces the engine out of memory anyway. One trick: cram a single upload part with an unlimited number of headers, which take more room in memory than they do on the wire. Another: use empty file fields that don't count against the upload cap but still eat memory. When the allocation finally fails, PHP exits in a half-finished state, and the shutdown code reads memory it shouldn't touch.

The second flaw, tracked as GHSA-6wmf-4rv5-p3rp, is a use-after-free, meaning the engine uses a piece of memory after it's already been handed back. PHP worker processes keep bits of global state (error info, session info, extension info) between requests. If a fatal error or even a mild warning fires at the wrong moment, that state still points at memory from the previous visitor's request after that memory has been freed. The next request then trips over it.

With a carefully arranged heap, both paths end at the same destination: remote code execution.

Who should care, and what should they do?

Patch this week if you run a website or API on PHP. Ask your host when they're patching if you don't manage the server yourself. That's the whole message.

For ordinary readers, there's nothing to click, nothing to install, no password to rotate. These bugs live on the server side, so the job sits with hosting providers, IT teams, and every hobbyist whose site runs on PHP.

My read: these aren't script-kiddie bugs. The multipart trick in the first flaw is clever precisely because it respects PHP's existing limits on paper while blowing past them in practice, the sort of thing that tends to survive a first round of mitigations. Reports seen by The Hacker News suggest exploitation probing has already started, which fits the pattern: public advisory, working proof somewhere in private hands, scanners live within days. We covered a similar sprint from patch to active exploitation in our 24 September story on WordPress 7.1.2.

A runtime bug like this isn't a WordPress problem or a Laravel problem. It's a problem for every PHP app sharing a host, which is why the fix has to happen at the language layer and why older, unsupported branches of PHP aren't getting one.