PHP2Shell added to CISA KEV catalog: first shells on honeypots

📌 Later developments: PHP2Shell on PAN-OS: fixes for five branches and Panorama (October 29, 2026) · PHP2Shell and Fragnesia: root on PAN-OS firewalls in 15 minutes (October 28, 2026)

On 26 October 2026 CISA, the US Cybersecurity and Infrastructure Security Agency, added the two PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities (KEV) catalog. US federal civilian agencies must fix them by Thursday 29 October. Over the same weekend the first public evidence of successful code execution appeared, although it was obtained on honeypots.

Our previous articles covered the announcement of the two flaws, the fixed versions released on 21 October, the third RCE CVE-2026-115560 and a week of exploitation attempts with no confirmed successes. What follows is what is new.

What the KEV listing means

According to The Register, the week before CISA had warned about the danger without having observed successful exploitation. The agency now considers both vulnerabilities actively exploited, but it has not named victims or attackers, nor shared details of the attacks. A spokesperson, quoted by The Record, pointed to the KEV rules, under which “active exploitation” covers both attempted and successful attacks. According to Computer Weekly, CISA does not know whether the flaws have been used in ransomware campaigns.

In practice, the listing confirms that the vulnerabilities are being targeted, not how many production systems have actually been compromised. The deadline applies only to US federal agencies, but CISA urges every organisation to prioritise the fixes.

In its updated advisory, reported by The Record, CISA asks organisations to:

• identify and inventory systems running any version of PHP;
• apply the fixes, or take offline the systems that cannot be updated right away;
• bear in mind that in some cases a web application firewall may provide protection for a limited period.

The advisory also links to guidance from PHP and from the agencies of Australia, Canada, New Zealand and the United Kingdom.

The first successful RCEs

According to The Register, on 24 October researcher Adel Karimi (Perplexity) recorded 35 successful shell executions on three honeypots running PHP 8.4.26 under Apache mod_php. Computer Weekly also reports remote code execution on a honeypot with the same version and configuration, which came to light on Sunday 25 October. The details, according to The Register:

• the attacks came from two IP addresses and used memory exhaustion and memory disclosure to reach code execution;
• once they had a shell, the attackers tried to contact external servers with PHP, curl and wget, without managing to download further malware;
• the activity is consistent with CVE-2026-109618, which Computer Weekly describes as memory corruption; there is no sign of CVE-2026-109619, a flaw tied to stale internal request state;
• Karimi warns that the honeypots had a favourable single-worker configuration: the results say nothing about how reliable the exploit is against production servers.

Again according to The Register, Delft University’s Threat Intelligence Lab has counted more than 50,000 exploitation requests from over 600 IP addresses in 70 countries; 171 of those addresses went beyond probing for vulnerable servers and sent exploit code or malware droppers. The sources do not publish the addresses: there are no public indicators of compromise.

Some earlier reports turned out to be premature: Sophos traced the activity it had observed to scanning and failed attempts, and Palo Alto Networks withdrew the link between the flaws and an intrusion at a European government agency (The Register, The Record).

On timing, CrowdStrike, quoted by Computer Weekly, explains that weaponising the exploits took longer because the PoC has to be adapted to the PHP version and the target application, which requires specific knowledge of Docker containers and packages. According to TechCrunch, the only source on this point, the two flaws had been known for two years but were considered not practically exploitable, until researchers at Calif found a method with the help of an AI model.

MITRE ATT&CK techniques: T1190 (Exploit Public-Facing Application) and, for the attempts to download tools with curl and wget, T1105 (Ingress Tool Transfer).

Patching: the numbers depend on the source

• According to the Censys dashboard cited by The Record, of the 42 million internet-facing PHP services more than 10 million have been updated since 21 October; on 22 October the figure was about 1 million.
• Infrawatch’s PHP2Shell Tracker, cited by Computer Weekly, counted about 443,000 visible hosts patched at 12:00 UTC on 27 October, around 20% of the total, with 31,000 more in the previous 24 hours: 27.2% in the UK and 19.7% in the US.

The two tools measure different populations and the absolute numbers cannot be compared, but both show that most exposed installations are still unpatched.

Impact for European and Italian companies

KEV is not binding on European companies, but it is a signal worth following. The sources point to where forgotten installations are likely to remain:

• small or unmaintained sites and PHP “hidden” inside larger products and platforms, including at external partners (William Wright, Closed Door Security, speaking to Computer Weekly);
• the backends of Android and iOS apps: according to NowSecure’s analysis reported by Cybersecurity360, the flaws do not affect phones, but a compromised PHP backend can expose the data and APIs used by apps, including services reached through third-party SDKs.

For NIS2 entities, the KEV listing should be documented as part of patch prioritisation, together with checks on suppliers that run PHP applications on the company’s behalf; any significant incident must be assessed for notification to the national CSIRT (in Italy, CSIRT Italia). In healthcare, patient portals, online booking and related apps should be checked first.

What to do now

1. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the fixed versions from your distribution or hosting provider, and check the version actually used by the web server, not just the one shown by php -v.
2. Unsupported versions: move to a supported branch or obtain fixes from your vendor; if that is not possible, take the system off the internet, as CISA advises.
3. Prioritise Apache mod_php: it is the configuration of the successful RCEs on the honeypots.
4. Use a WAF only as a temporary measure until you can update.
5. Keep session.upload_progress.enabled disabled if you already did so for CVE-2026-115560: the third flaw is not fixed yet.
6. Ask your suppliers to confirm the update of applications, hosting and mobile app backends.
7. Look for signs of compromise: PHP processes spawning shells, curl or wget, unexpected outbound connections from web servers, anomalous requests in the logs.

How ARXDOME helps

ARX Shield shows, for each machine, open vulnerabilities by package, highlighting those already exploited. The ARX Sentry inventory lists software and processes on servers with the agent, which helps find PHP and PHP-FPM. ARX Expose shows which of your company’s public services expose recognised products, so you can start with those reachable from the internet.

Last updated: 27 October 2026