CISA Adds PHP2Shell Flaws to KEV Catalogue, Lists 29 October Deadline

Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, were added to the US Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalogue on 26 October 2026. Both catalogue entries list 29 October as their due date and refer to forensic triage under Binding Operational Directive (BOD) 26-04, whose requirements apply to covered federal civilian executive branch systems. The listing follows reports of exploitation attempts beginning before the vulnerabilities were publicly disclosed; it does not establish compromise of any particular Drupal installation.

The official catalogue records classify both flaws as known exploited and identify ransomware campaign use as unknown. However, inclusion in the catalogue does not independently establish that a production Drupal website has been compromised. The listed deadline and forensic-triage requirements must be interpreted under BOD 26-04, which applies to federal civilian executive branch systems and establishes risk-based requirements depending on asset exposure and other factors. The 29 October date is not a universal patching or compliance deadline for Drupal websites outside the directive’s scope.

The development adds urgency to the response already underway across Drupal hosting environments. The PHP project released corrected versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 21 October. Because the vulnerabilities affect the PHP runtime rather than Drupal itself, updating Drupal core or contributed modules does not resolve the underlying flaws.

A technical account published on 26 October by Aman Pathak, senior DevOps and cloud engineer at Specbee, describes how the agency patched or mitigated exposure across more than 30 enterprise Drupal client sites within 24 hours. The environments included AWS Elastic Container Service (ECS), dedicated servers, GovCloud and client-managed cloud infrastructure. Specbee reports completing the response without downtime.

For 16 ECS services, the agency rebuilt container images with updated PHP packages and deployed them through rolling replacements. Other environments received PHP updates and PHP-FPM reloads, while a government installation required rebuilding a custom PHP binary. Legacy sites running unsupported PHP versions received temporary configuration-level mitigations, with full upgrades remaining a separate task. Such mitigations do not provide the same protection as installing corrected PHP releases.

Specbee also conducted retrospective checks covering 17–22 October, examining server logs, PHP session files, potentially malicious files and newly created Drupal administrator accounts. The agency reported no matches for six attacker IP addresses identified by Amazon Threat Intelligence and reported finding no evidence of compromise in the available records examined. However, some session data was unavailable because containers had already been replaced, limiting the completeness of the investigation.

These limitations reinforce the Drupal Association's earlier guidance on post-patch auditing, which recommends preserving available evidence and examining activity dating back to 17 October. Patching addresses the known vulnerabilities but cannot establish whether exploitation occurred before the fixes were installed. Drupal hosting teams therefore need to confirm that affected PHP installations are corrected while separately assessing historical exposure and the records available for investigation.