PHP2Shell, in plain English

On 21 October 2026 PHP shipped an emergency security release: 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They have been nicknamed “PHP2Shell”. PHP’s own advice is blunt: “There are no complete mitigations, updating is the only safe choice.”

Here’s what’s going on, without the jargon.

How PHP handles a visit

Every time someone visits a PHP website, a PHP “worker” on the server handles that visit, then moves on to the next visitor. Before your website’s own code starts, PHP does some housekeeping: it reads its settings and unpacks whatever the visitor sent, such as form fields and file uploads.

Both flaws live in that housekeeping.

Flaw 1: the room isn’t cleaned between guests (CVE-2026-109619)

Imagine a hotel where housekeeping sometimes leaves the last guest’s notes behind. PHP workers kept a few references to the previous visit, such as error handlers and session state, pointing at memory that had already been thrown away. A crafted request can make PHP use those stale references, and whoever controls what now sits in that memory can steer what PHP does next.

PHP’s advisory names two confirmed ways in: the session upload progress feature, and warnings raised while PHP applies its settings at start-up.

Flaw 2: walking off mid-job (CVE-2026-109618)

When a request ran out of memory, PHP used to stop instantly, mid-task. Anything half-built was left lying around, and the clean-up then treated it as finished. Same result: corrupted memory an attacker can steer.

The fix changes how PHP handles running out of memory: it now finishes the current operation safely and exits cleanly, rather than jumping out halfway through.

What an attack looks like

From the outside it’s just a form submission, the kind of request a website handles all day. It doesn’t need a login or an upload page, and it doesn’t matter what the site does, because it hits PHP before the site’s code runs.

Researchers have reported working attacks against WordPress, Drupal, Magento, Joomla, Laravel, Symfony, Nextcloud, phpMyAdmin and more. PHP rates Apache’s mod_php setup as highest risk; PHP-FPM is confirmed vulnerable to CVE-2026-109619 as well.

What’s at stake

A successful attack lets someone run their own code on your server. In practice that means reading database passwords and API keys, planting a hidden backdoor, or injecting card skimmers or spam into your pages. Sansec also reports that one of the flaws can leak data from other visitors’ requests, such as session tokens and passwords.

Cloudflare and watchTowr both reported attacks on 21 October.

What to do

Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or your host or distribution’s patched build.
Fully restart PHP afterwards: a restart, not a reload, so no old workers keep running.
On PHP 8.1 or older? There’s no official fix. PHP points people to distribution and long-term-support vendors for backports; otherwise it’s time to upgrade.
If a site sat unpatched, look for warning signs: new admin users, unfamiliar PHP files, unexplained errors or worker restarts.

Turning off session upload progress or putting a firewall in front reduces the risk while you wait for a patched build, but neither is a fix. I’ve written up why the upload progress setting isn’t a fix separately.