PHP issued an emergency out-of-band patch today for two critical RCE flaws dubbed PHP2Shell, rated 9.2 on CVSS v4.0, and sury.org has already published the builds for Debian and Ubuntu. The four current branches get native fixes, 8.5.12, 8.4.27, 8.3.36, and 8.2.35, while the seven end-of-life branches from 8.1 down to 5.6 get the same protection backported. Since the bugs permit unauthenticated RCE and memory disclosure across every deployment model, PHP says updating is the only reliable fix, though interim steps like disabling session.upload_progress can buy a little time. Operators can update in place with a standard apt command and then restart PHP-FPM or Apache, sidestepping the emergency migration many had feared.

Sury.org now ships PHP2Shell protection across every PHP branch for Debian/Ubuntu, oldest back to 5.6

For the many of you still running legacy PHP, today's backports may just save you a migration.

Good news for anyone still wedded to legacy PHP, and it's the kind of update that changes the whole framing. As of this afternoon, Ondřej Surý's Debian and Ubuntu repository carries a PHP2Shell backport all the way down the branch ladder, to PHP 5.6 included.

That flips the usual "upgrade or die" message on its head. You no longer have to rip out a decade-old PHP install to survive this particular flaw.

An out-of-band release from the PHP project fixed two critical remote code execution vulnerabilities, collectively dubbed PHP2Shell, rated 9.2 on CVSS v4.0 — and sury.org has made sure every branch it maintains carries protection against them.

Four branches get the fix natively, rebuilt from the upstream release. The other seven are end-of-life, so sury.org is backporting the fix into packages it maintains. Either way, the outcome is the same: a vulnerable box on PHP 5.6 is no longer a sure thing for an attacker.

The two CVEs

Both bugs share one root cause the PHP team describes as state corruption during a memory bailout. When a request dies abnormally, usually from running out of RAM, internal state gets left half-initialized. The next request that worker handles then acts on data that was never meant to be valid.

CVE-2026-109618 rides an out-of-memory error through a crafted multipart upload, which makes the memory exhaustion controllable. CVE-2026-109619 is nastier: request-owned state can survive after its memory is freed, leaking into a later request, with session.upload_progress as the reliable trigger, and fatal_error_backtraces on PHP 8.5.

Here's the part that makes operators pale, and it still stands: it's not just RCE. The corruption can leak memory too, so passwords, session tokens, API keys, and certificates from other requests can be read out of a worker's RAM.

PHP's advisory was blunt — no complete mitigations exist, only updating helps. Cloudflare confirmed in-the-wild attacks before the patch shipped, and the UK's NCSC urged organizations to update or take PHP offline. The researchers, from Wiz, OpenAI, and Calif, demonstrated working exploits against WordPress, Drupal, and Joomla. They'll admit, though, that even a bare "Hello World" on affected PHP is vulnerable.

What shipped today

The four supported branches line up exactly with upstream:

The seven end-of-life branches, 8.1.34, 8.0.30, 7.4.33, 7.3.33, 7.2.34, 7.1.33, 5.6.40, are the ones that matter for this story. Each still gets the PHP2Shell fix through backporting.

Why the EOL backports are the real win

sury.org's model is straightforward. For a dead branch, it takes that branch's final upstream release, the version that already holds every security fix PHP ever shipped for it — and keeps repackaging it across changing system libraries so it stays installable. The -N revision count just tracks how many times a branch has been repackaged. PHP 5.6 has accumulated 104 of them.

Now that list includes the PHP2Shell fix. So an operator on PHP 5.6.40 or 7.2.34 no longer has to panic. They get protection without the rewrite.

That said, keep in mind these backported builds predate this CVE at upstream, so the mechanism here is a deliberate backport, not an upstream patch. Reading the package changelog before you deploy is worth the five minutes — a backport can quietly change behavior, like disabling a feature you depend on.

How to apply it

On sury.org it's a standard apt workflow. You need a source pointing at https://packages.sury.org/php/ and the official keyring imported, which per the project's own README.txt looks like this:

# As root (or with sudo)
apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb \
    https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] \
    https://packages.sury.org/php/ $(lsb_release -sc) main" > \
    /etc/apt/sources.list.d/php.list'
apt-get update

Once that's in place, upgrading is a single command:

apt-get update
apt-get install --only-upgrade php            # or a specific SAPI, e.g. php-fpm, php-cli 

Head here to the Sury.org website.