Published on gastropod.io on 10-28-2026

CISA Added Both PHP2Shell Flaws to the KEV Catalog; the Open Question Is Which of Your Images Carry an Unpatched PHP

Tags: vulnerability-intelligence, software-supply-chain-security, php, oci-containers, remote-code-execution, cisa-kev, sbom

CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on October 26 and set a October 29 remediation deadline for federal civilian agencies under Binding Operational Directive 26-04 (CISA). The PHP Foundation released patches on October 21 and rates both at CVSS 9.2, with unauthenticated remote code execution for each.

CVE-2026-109618 is a memory corruption flaw: when PHP runs out of memory while its internal request data is only partly initialized, the cleanup that follows treats that data as valid. CVE-2026-109619 is a use-after-free in which leftover state from one request points to freed memory that a later request on the same worker can reach. Every PHP installation serving web requests is affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP Foundation rates mod_php highest risk, because an unauthenticated request triggers the demonstrated exploit before any application code runs. Calif.io traces the earliest affected code path to PHP 5.4.0 (Tenable).

The fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 7.4 through 8.1 received minimal source backports with no official release, and 5.4 through 7.3 get nothing from the project. Distributions and LTS vendors received patches in advance, so a packaged PHP follows the vendor's version numbering rather than upstream's.

Amazon Threat Intelligence recorded an exploitation attempt against its MadPot honeypots on October 17, four days before disclosure, and recommends investigations start from that date. Cloudflare, Hadrian, watchTowr, Previdian, and Patchstack all observed attempts before the patch and assessed them as unsuccessful. Adel Karimi, detection and response lead at Perplexity, reported the first confirmed exploitation on October 24: three honeypots running PHP 8.4.26 under single-worker mod_php, with shells executing attacker commands, matching CVE-2026-109618 rather than CVE-2026-109619. Trail of Bits reported working exploits against pre-patch PHP 8.2 through 8.5. VirusTotal counts more than 5.1 million PHP hosts reachable online, about 3.8 million with at least one port open (BleepingComputer, The Register).

Three operational details to consider in your remediation plan

Installing a patched package does not patch a PHP process that is already running, so PHP-FPM, Apache, and every other PHP worker needs a restart afterward. Google Cloud, with input from Mandiant, advises capturing worker memory on any suspect server before that restart, because restarting erases the evidence.

PHP 8.4.27 and 8.5.12 crash some applications that use SimpleXML, traced to a separate garbage collector change. A fix is merged upstream and had not shipped in a release as of October 26, so the exact patch build a service runs determines whether it works.

The Windows builds dated October 26 (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) also fix CVE-2026-111497, the Brotli decoder flaw, at the same PHP source version. Two builds with the same PHP version string are not the same artifact.

Where interim configuration is the only option, the PHP Foundation's guidance is memory_limit=-1 set so applications cannot override it for CVE-2026-109618, and session.upload_progress.enabled=0 for CVE-2026-109619, with fatal_error_backtraces=0 additionally on 8.5. Restart all workers after either change. CERT-EU recommends isolating internet-facing applications until patches are applied and verified.

Nobody should need convincing to patch a KEV entry with a three-day federal deadline.

The work that takes longer is actually producing the list of what you need to patch. PHP reaches a build through several paths at once: the php package from a Debian, Ubuntu, Alpine, or RHEL-family repository; an official php base image that a Dockerfile builds FROM; a vendor appliance image with PHP inside it; and a Windows build with its own suffix. A service in the first category reports the distribution's version string, not upstream's, so matching against 8.2.35 returns the wrong answer. A service in the second category may not list PHP as a dependency anywhere, because it arrives as part of the base image. This is the same gap as the bundled OpenSSL copies I have already covered here: https://gastropod.io/news/eleven-bytes-no-cve-the-openssl-hollowbyte-flaw-that-scanners-miss.

Shameless plug for Gastropod.io.....

Gastropod proxies the sources those builds come through: OCI registries, Debian and Ubuntu, Alpine apk, the RHEL family, and Composer's upstream through its source proxies. Every artifact it serves gets a PURL, a sha256 digest, and a where-seen history, and Gastropod reconstructs a CycloneDX SBOM for any of them on demand, so the PHP inside a base image is recorded as a component rather than being invisible behind the image tag. Gastropod correlates OSV advisories at the specific version, which keeps a distribution's backported build distinct from the upstream number it was derived from. The blast-radius graph lists which of your services pulled an affected image or package, and a block rule at intake stops an unpatched PHP image from entering a new build while the rollout proceeds. Because the audit spine records the digest and timestamp of every pull, the record also shows which hosts pulled a patched build and when, which is the starting point for checking that workers actually restarted.

Gastropod does not patch PHP, restart workers, or confirm that a running process loaded the new binary. It answers the inventory question that comes first. The product page shows the SBOM, blast-radius, and audit views, and you can point Docker and your package managers at Gastropod from app.gastropod.io/start.

Sources: