CISA adds two PHP flaws to exploited-vulnerability list, sets Oct. 29 federal deadline

CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on October 26, after saying on October 21 that it had not observed exploitation. [1]

The PHP2Shell flaws can enable unauthenticated remote code execution in PHP installations serving web requests. [2]

The PHP project fixed the bugs in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier require an upgrade or a backported fix from a supported vendor. [3]

Public reporting shows active scanning and some successful exploit attempts, but CISA has not disclosed victims or the evidence behind its KEV entries. [4]

The U.S. Cybersecurity and Infrastructure Security Agency has added two critical PHP vulnerabilities to its list of flaws exploited in attacks, giving federal civilian agencies until Thursday, October 29, to fix affected systems. The move changes CISA’s assessment from October 21, when the agency said it had not observed exploitation of the vulnerabilities. [5]

Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively called PHP2Shell, the flaws can allow an unauthenticated attacker to execute arbitrary code on a vulnerable server. The PHP Security Team released patches on October 21, and CISA has urged organizations to prioritize internet-facing systems. [2]

What the PHP flaws affect

The vulnerabilities are in the PHP runtime, not in a specific content-management system or plug-in. A site can therefore remain exposed even when its WordPress, Drupal or other application code is current if the underlying PHP installation is vulnerable. PHP’s advisory lists PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected serving environments. [2]

The two bugs have different technical paths. CVE-2026-109618 involves out-of-memory handling that can leave request data in an invalid state; CVE-2026-109619 involves stale internal state being reused after its backing memory has been freed. The PHP project rates both vulnerabilities critical and says they can lead to remote code execution. [6]

The PHP project considers the risk highest for mod_php, where a demonstrated exploit can trigger the vulnerable behavior before application code runs. It describes PHP-FPM as susceptible in some circumstances but says a complete application-independent exploit has not been demonstrated for that SAPI. [6]

Evidence of exploitation is growing, but exposure is not uniform

Independent researchers have reported evidence that at least some attackers can achieve code execution. The Register reported that Perplexity researcher Adel Karimi recorded 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php. The findings were consistent with exploitation of CVE-2026-109618, although the researcher did not establish that CVE-2026-109619 was involved. [7]

The same report cited Delft University’s Threat Intelligence Lab as tracking more than 50,000 PHP2Shell exploitation requests from more than 600 IP addresses across 70 countries. Only a subset of those addresses reportedly moved beyond probing and sent exploit code or malware droppers. Those figures show active targeting, but they do not establish that every PHP website is exploitable in the same way or that production systems were breached at scale. [7]

CISA’s KEV designation confirms that the agency considers both CVEs actively exploited, but its public listing does not identify compromised organizations or quantify successful intrusions. Other researchers have also revised earlier claims that activity represented confirmed PHP2Shell exploitation. [4]

The patch and the administrator checklist

The PHP project fixed the two CVEs in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It says updating is the only complete mitigation. PHP 8.2 is scheduled to reach end of life on December 31, 2026. [3]

Administrators should inventory PHP directly and through third-party products, appliances, containers and hosting environments. They should identify internet-facing deployments and upgrade each supported branch to its fixed release. Organizations still running PHP 8.1 or earlier should their operating-system or commercial support vendor for a backported fix, or move to a supported PHP branch. CISA advised taking systems offline if they cannot be updated promptly. [2]

The PHP Security Team disclosed a separate remote-code-execution issue, CVE-2026-115560, on October 23. The October 21 releases do not address that flaw. The Canadian Centre for Cyber Security says the issue requires an uncommon configuration and application behavior; where applicable, it recommends temporarily disabling PHP’s session upload progress feature with `session.upload_progress.enabled=0` until a fix is available. [8]