CISA Confirms Active Exploitation of Two Critical PHP Flaws

The U.S. Cybersecurity and Infrastructure Security Agency has confirmed that attackers are actively exploiting two critical vulnerabilities in PHP web software, and it has ordered U.S. civilian federal agencies to fix their systems within three days of its warning.

The two flaws, tracked as CVE-2026-109618, a PHP Memory Corruption Vulnerability, and CVE-2026-109619, a PHP Stale Internal Request-State Vulnerability, allow remote compromise over the internet without passwords, according to TechCrunch. On 26 October 2026, CISA added both identifiers to its Known Exploited Vulnerabilities Catalog. Five days earlier, on 21 October, the agency had published an alert titled "Critical Vulnerabilities in PHP Require Immediate Patching," which described the flaws as "php2shell" and said they allow unauthenticated remote code execution (CISA).

The reach of the bugs is considerable. TechCrunch reports that PHP is used by about 70% of web-facing servers.

PHP's own timeline is compact. The project scheduled a security release addressing two critical vulnerabilities for 21 October 2026 at 14:00 UTC, and it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix them (PHP.net). The patches therefore reached users less than a week before CISA's exploitation warning. The project identified CVE-2026-109618 and CVE-2026-109619 as the two critical issues in that release.

The vulnerabilities have a longer history than the release cycle. TechCrunch reports that they were first uncovered two years ago, but the maintainer left them unpatched after concluding there was no practical way to exploit them. Earlier this year, researchers at the security firm Calif found a way to exploit the dormant flaws with the assistance of an AI model. The bugs have since been referred to as PHP2Shell.

OpenAI has said that it led a coalition of maintainers, researchers and security providers over two months to address critical vulnerabilities in PHP, and it published its account of the coordinated disclosure on 21 October 2026 (OpenAI).

The broader context here is the gap between an assessment of exploitability and the reality of exploitation. A maintainer's judgment that a memory corruption bug has no practical exploit path was a reasonable reading of the state of the art when it was made. The Calif work suggests that the calculation can change once a capable model is put to the problem, and that a flaw parked in a backlog can become live without any change to the code itself. Defenders who triage by "not currently exploitable" labels may need to revisit those labels more often.

For operators, the immediate arithmetic is simpler. A three-day window for federal civilian agencies is short, but it is set against a patch that has been public for under a week and a vulnerability class that does not require credentials. Any PHP deployment reachable from the internet, including the many that run as shared hosting, content management back ends or internal tooling exposed through a reverse proxy, belongs on the same list. Upgrading to the fixed branch is the straightforward remedy. Verifying that the upgrade actually reached every web-facing host, including containers and forgotten staging servers, is where most of the work will sit.

In my view, the most useful lesson for the people who run this software is procedural. Coordinated disclosure worked here in the sense that patches existed before the public exploitation warning. The window that mattered was the one between a patch becoming available and an installed base actually moving to it, and that window is measured in change-control cycles rather than in advisories.