CISA lists both PHP2Shell flaws as exploited, sets 29 October deadline

CISA lists both PHP2Shell flaws as exploited, sets 29 October deadline

26 October 2026: The US Cybersecurity and Infrastructure Security Agency has added CVE-2026-109618 and CVE-2026-109619, the pair of PHP flaws known as PHP2Shell, to its Known Exploited Vulnerabilities catalog. Both allow unauthenticated remote code execution, both are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the listing means CISA has evidence of attacks. US federal civilian agencies must act by 29 October, three days after the listing.

The PHP project released the fixes on 21 October and its own announcements did not report exploitation at the time. Our first report on the fixed versions covers how the two bugs work; this item covers what changed with the KEV listing.

What the two catalog entries say

CISA names the first flaw, CVE-2026-109618, a PHP memory corruption vulnerability, describing an out-of-memory corruption that allows unauthenticated remote code execution. The second, CVE-2026-109619, is a stale internal request-state vulnerability with the same result. Both entries list the PHP Group as vendor, carry a due date of 29 October and mark known use in ransomware campaigns as unknown.

The required action points to Binding Operational Directive 26-04: apply the vendor's mitigations, follow the directive's guidance for cloud services, or stop using the product where no mitigation is available. Both entries are also flagged for CISA's forensic triage requirements, so an agency that ran an exposed, unpatched PHP host is expected to check it for compromise, not only to patch it. The catalog notes that PHP is an open-source component used inside many other products, which is why appliance vendors have been publishing their own notices.

Japan's IPA updates its alert

Japan's Information-technology Promotion Agency first warned about the pair on 22 October and updated its alert on 27 October to record the KEV listing. IPA says it has not confirmed attacks in Japan. It lists every PHP release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected and points out that PHP 8.1 and older, which are past end of life, receive no fix. Where an update cannot be applied straight away, IPA advises blocking access from outside or suspending the service.

Which hosts to check first

The fixed releases are the only complete answer. The places where an unpatched PHP most often survives are the ones nobody updates by hand: container base images pinned to an older minor version, vendor appliances that bundle their own PHP, and shared hosting plans where the provider controls the runtime. We have already reported one such case, the Palo Alto Networks management interfaces, where the fix depends on the vendor.

Our catalogue lists 201 companies in its web hosting category. Customers on managed plans should ask their provider which PHP build each site runs and when it moved to the fixed release. Teams running their own servers should also restart PHP workers after upgrading, since a long-running process keeps the old code in memory until it is replaced.

CISA's due date binds only US federal civilian agencies. For everyone else the listing is the signal that attacks are under way.

Sources

• CISA: Known Exploited Vulnerabilities Catalog, entries for CVE-2026-109618 and CVE-2026-109619 (catalog release of 26 October 2026), 26 October 2026
• IPA: alert on the PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (published 22 October, updated 27 October), 27 October 2026
• PHP: release announcements for 8.5.12, 8.4.27, 8.3.36 and 8.2.35, 21 October 2026