PHP2Shell is in CISA KEV: why runtime visibility matters

Five days after PHP shipped the fix, CISA added both PHP2Shell flaws to its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies have until October 29 to remediate.

Last week’s question was whether attackers could turn the flaws into working shells. This week’s question is which of your images and hosts still run an affected PHP build, and who can fix each one.

What changed

On October 26, 2026, CISA added CVE-2026-109618 and CVE-2026-109619 to the KEV catalog and updated its PHP alert. The due date for federal civilian agencies is October 29. CISA encourages all other organizations to prioritize the fixes, though the deadline does not bind them, per BleepingComputer.

A week earlier, CISA had warned about PHP2Shell but said it had not yet observed successful exploitation, per The Register. CISA has not named compromised organizations or described the attacks behind its decision.

The public evidence arrived over the weekend. On October 24, Perplexity researcher Adel Karimi recorded 35 successful shell executions. The targets were three honeypots running PHP 8.4.26 under Apache mod_php. The activity matched CVE-2026-109618, and Karimi found no evidence that the second flaw was involved.

The attackers then tried to reach external servers with PHP, curl, and wget. No additional malware downloaded. Karimi also cautioned that the honeypots ran a single-worker configuration that favors the exploit. The results do not show how reliably the attack works against production servers.

Scale is the other half of the story, and it measures attempts, not compromises. As of October 27, Delft University’s Threat Intelligence Lab has tracked more than 60,000 PHP2Shell exploitation requests from over 600 IP addresses across more than 70 countries. Of those addresses, 171 moved past probing and sent exploit code or malware droppers. Amazon Threat Intelligence dates the first exploitation attempts to October 17, four days before the patches, per BleepingComputer.

One correction worth knowing. Sophos withdrew its initial report of successful attacks after concluding the activity was scanning and failed attempts. Palo Alto Networks withdrew a claim linking the flaws to an intrusion at a European government agency. CISA’s KEV listing confirms active exploitation. It does not say how many production systems were breached.

Who is still exposed

Both flaws sit in the PHP runtime, not in any application built on it. The affected releases are PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12, per the PHP security team. PHP says every installation serving web requests is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, with the highest risk on mod_php, per CISA.

Being at risk is not the same as being easy to exploit. PHP rates attack complexity as high and says exploitability depends on configuration and application behavior. For CVE-2026-109618, PHP validated remote code execution against mod_php but reports no complete FPM exploit. For CVE-2026-109619, PHP validated remote code execution against both mod_php and FPM.

PHP 8.1 and older are end of life and get no fix from the PHP project. Teams on those branches need a vendor-supported build or an upgrade. The Register adds that systems you cannot secure should come offline until you can.

What a three-day deadline tells you

CISA gave federal agencies three days. Read that as a measure of urgency, not a statement about how long patching takes. Agencies meet a deadline like that only if they can answer three questions fast: where the flaw runs, how exposed each instance is, and who ships the fix.

That is the gap PHP2Shell keeps finding. The KEV listing names two CVEs. It cannot name your affected assets. The PHP runtime arrives through a server package, a hosting plan, or a container base image, and each usually has a different owner. A Composer lock file records your libraries, not the PHP build that runs them.

Last week was about patching the builds you knew about. This week is about the ones you did not.

From finding to fix

A CVE match tells you a vulnerable package exists. It does not tell you what to fix first, or how. PHP2Shell shows why that context matters.

The same flaw carries different risk in different places. PHP rates mod_php highest, and its validated exploits depend on the server API and configuration. An internet-facing mod_php server is a different problem from an admin panel reachable only on a private network.

The fix path differs too. A host package needs a vendor update and a worker restart. A container image needs a patched base image, a rebuild, and a redeploy. A managed host needs an answer from the provider. A distribution package may already carry the fix under an unchanged version number.

Until a finding is tied to an asset, an exposure level, and an owner with a fix path, it is information, not action.

How to find it and fix it

1. Close the inventory. List every container image with a PHP package or a PHP base-image tag. Add every host with a PHP package installed. Ask every hosting or PaaS provider which version runs for you. Include internal tools and admin panels. For each one, record whether it serves web requests, which server API runs PHP, and who owns it.
2. Upgrade and rebuild. Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to a distribution package that carries the fix. Rebuild container images from a patched base image, then redeploy them. For images that build PHP from source, such as the official php images on Docker Hub, run php -v inside the running container rather than trusting the tag. For distribution packages, check the package release against your vendor’s advisory. Distributions backport fixes, so php -v can show the same version before and after.
3. Restart every PHP worker. Apache, PHP-FPM, and long-running workers need a restart after the update to load the fixed binary.
4. Treat mitigations as a bridge. If you cannot upgrade today, PHP’s advisories list configuration mitigations, each followed by a worker restart. PHP says updating is the only reliable fix.
5. Review hosts that stayed exposed. Any system that served requests unpatched after October 17 deserves a log review before you call it clean. Include outbound connections from PHP processes, since the honeypot attackers tried to reach external servers.
6. Plan the next upgrade now. PHP 8.2 reaches end of life on December 31, 2026, per php.net. A team that patched to 8.2.35 bought weeks, not a year.

Where Mend.io fits

Mend.io helps connect a vulnerable package to the image it lives in and the change that fixes it.

Identify affected components. Mend.io container scanning checks container images for vulnerable operating system packages across the distributions in its support matrix. That includes Debian, Ubuntu, Alpine, SUSE, and Red Hat Enterprise Linux. It reaches the PHP that arrives through a base image’s package manager, the layer an application inventory usually misses. Mend SCA continues to cover the open source dependencies your application declares, such as Composer packages.

Prioritize exposure. Container findings sit alongside the rest of your open source risk, so a KEV-listed runtime flaw is in front of the teams that already triage application findings. The context in the previous section still decides the order: which images serve web traffic, which server API they use, and who owns each one.

Accelerate remediation. Mend Renovate opens pull requests to update Dockerfile base-image tags when a new image version publishes, including the official php images. The move from an affected PHP tag to a fixed one arrives as a reviewable change where the image is defined. Your teams merge, rebuild, and redeploy.

The broader lesson

PHP2Shell went from patch to KEV listing in five days. The advisories, fixed versions, and exploitation evidence were all public within that week. For many teams, the harder part was knowing where the flaw ran and who could fix it.

That is the lesson to carry into the next KEV listing. Vulnerability intelligence becomes useful only when it connects to an affected asset and a remediation path. Teams that can make that connection treat a three-day deadline as a work queue. Teams that can’t must start by searching.