A week after PHP shipped fixes for the two critical PHP2Shell flaws on October 21, 2026, the post-mortems published by the PHP Foundation and FOSS Pub point to a lesson every sysadmin can act on: how fast a server got patched depended less on PHP itself than on who packaged its interpreter and whether that branch was still supported. The bug was first spotted in 2024, one vendor shipped fixes hours before the official release, and some installations could only get the patch through paid support.

PHP2Shell lessons for sysadmins in 30 seconds

PHP fixed CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws, on 21/10/2026.
Chainguard published patched builds more than six hours before PHP, which the PHP Foundation calls an embargo break.
Debian packages followed twelve minutes after PHP; Debian 11 and older Ubuntu releases needed paid extended support.
PHP 8.1 and older only got source patches, and Germany’s BSI advised taking unpatched web servers offline until they could be fixed.

On the day itself, this site covered what sysadmins should do before and after the patch, from inventory to temporary mitigations. The post-mortems add the missing context: why the fix took so long, why it reached servers at very different times and which systems were left without an official package.

The package source decides when the fix lands

According to the PHP Foundation, Chainguard, which sells ready-to-use builds of open source software, published its patched PHP packages at 07:41 UTC. PHP released at 13:33 UTC, and Debian shipped its packages twelve minutes later thanks to Ondřej Surý, the volunteer who packages PHP for Debian and Ubuntu. In between, the patched code was public, so anyone could diff it against the old version to locate the bug while most servers were still waiting for their distribution.

The PHP Foundation says Chainguard broke the embargo. Chainguard CEO Dan Lorenc argued, as Socket reports, that he released early because exploits were already circulating. Whoever is right, the operational takeaway is the same: know where every PHP install comes from (distribution packages, Surý’s repository, Remi’s on Red Hat systems, third-party container images or in-house builds) and follow that source’s security notices. These commands help confirm the origin and whether the installed package already includes the fix:

# Which repository does the installed PHP come from? (Debian/Ubuntu)
apt-cache policy php8.3

# Does the installed package include the fix? (Debian/Ubuntu)
apt changelog php8.3 | grep -E 'CVE-2026-10961(8|9)'

# Same check on RHEL, Rocky, Alma or Fedora
dnf info php
rpm -q --changelog php | grep -E 'CVE-2026-10961(8|9)'Code language: PHP (php)

A changelog entry is not enough if running processes still use the old binary. PHP-FPM or Apache must be restarted, and containers need to be rebuilt on the patched base image and redeployed.

Unsupported branches were the weak spot

According to FOSS Pub, Debian 11 only received the fix through Freexian’s paid extended support, older Ubuntu releases through Ubuntu Pro, and PHP 8.1 and earlier only got source patches. Hand-installed PHP 7.x and old images were left with no official package and two options: build with the patch or migrate. PHP’s supported versions page is the reference for which branches still get security fixes.

Germany’s federal information security office, the BSI, showed the fallback when patching is not possible. It raised its alert to orange and advised temporarily disconnecting unpatched web servers from the internet, and the federal criminal police office (BKA) and several state governments did so. It is a drastic step, but for an internet-facing service with an unauthenticated RCE and no patch available, taking it offline or restricting access through a VPN or IP allowlist may be the least bad option.

The origin of the bug matters too. The PHP Foundation says one of its developers saw early signs of it in 2024 while fixing findings from a Quarkslab audit funded by Germany’s Sovereign Tech Agency, but the fix stalled for lack of consensus and people until the firm Calif reported a working exploit on August 11, 2026. The Foundation now plans to decide by majority and escalate hard cases sooner. A Spanish-language account of that timeline is available on Opensecurity. For operations teams, the homework is the same as ever, only more urgent: keep an inventory of PHP versions, know who packages them and retire unsupported branches before the next alert.

Frequently asked questions

What is PHP2Shell?

The name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated code execution on a web server. They were fixed on October 21, 2026.

How can I check whether my PHP package includes the fix?

Search the installed package changelog for both CVE IDs with apt changelog or rpm -q –changelog, then restart PHP-FPM or Apache so the new binary is used.

What about PHP 8.1 or PHP 7?

PHP 8.1 and older only received source patches. On unsupported distributions such as Debian 11, the fix arrived through paid extended support.

Why did some vendors ship the patch earlier than others?

Chainguard published its builds more than six hours before PHP, which the PHP Foundation considers an embargo break; distributions followed the official release.

Sources: