php2shell: what is confirmed five days on

Five days after the PHP patches the picture is contradictory. Unit 42 has retracted its update on an intrusion carried out with an AI agent, still repeated by many outlets. The first confirmed code executions come from honeypots, CrowdStrike and ReliaQuest see no successful compromises at customers and the CVEs are not in the KEV catalogue. Meanwhile most installations with a visible version run branches that will get no fix.

CybersecurityCybersecurityPHPVulnerability managementRCEPatch managementThreat intelligence

Article

Four figures on what is confirmed about php2shell exploitation
Data from Unit 42, CISA, SecurityWeek, CrowdStrike, ReliaQuest, Bitsight and Recorded Future. Sources at the end.

On 21 October PHP released fixes for CVE-2026-109618 and CVE-2026-109619, the vulnerabilities known as php2shell. Five days later there is plenty of news about exploitation and it does not all point the same way. It helps to separate four levels: exploitation attempts, code execution on honeypots, compromises of real systems and retracted news.

Unit 42’s retraction

On 23 October at 12:30 (Pacific time) Palo Alto Networks’ Unit 42 added to its threat brief the details of an intrusion against a European government agency: post-compromise activity it attributed to an agentic AI platform, with threat hunting queries. The story was widely picked up as the first php2shell attack carried out by an AI agent.

On 25 October at 14:15 Unit 42 retracted that update. The note explains that the activity had been observed in a vulnerable PHP application, but that the team cannot confirm initial access was linked to the php2shell CVEs. The retraction concerns the link with php2shell: Unit 42 says nothing more about the intrusion.

Several articles and vendor blogs still present the case as a php2shell attack by an AI agent, and one attributes it to a state-sponsored group. They are reconstructions based on an update the source itself no longer stands behind.

What has actually been observed

Attempts. They are documented since before the release: Amazon saw them in its honeypots from 17 October, Cloudflare from the 21st, as we wrote in our first piece.

Code execution on honeypots. According to SecurityWeek, Adel Karimi, a researcher at Perplexity, recorded 35 shells on 24 October across three honeypots running PHP 8.4.26, Apache mod_php and a single worker. The chain has four stages: some requests exhaust memory, others leak its contents, the last runs a command. The traffic matches a public proof of concept and is consistent with CVE-2026-109618. No second-stage payload download was observed. Karimi himself warns that the setup is deliberately favourable and does not measure exploit reliability with other worker counts, builds or applications. Marcus Hutchins (Expel) calls it by far the highest quality confirmation of in-the-wild exploitation he has seen so far.

Compromises of real systems. No primary source has confirmed any:

  • ReliaQuest (update of 22 October) has not observed successful exploitation in customer environments; it achieved code execution in the lab, where the prerequisites were already in place;
  • CrowdStrike (23 October) has not observed successful exploitation in the wild or in its honeypots: many proofs of concept only crash the process, and an attacker has to adapt them to the target’s PHP version and application. A universal exploit is unlikely, one for specific profiles such as a fixed Docker image is feasible;
  • CISA, according to SecurityWeek, updated its alert on 23 October with a Sigma detection rule, stating it had not observed successful exploitation. The two CVEs do not appear in the KEV catalogue, whose latest version is dated 23 October.

Exposure

The available figures measure exposed installations, not confirmed vulnerable systems, and the methods differ:

  • Unit 42 (Cortex Xpanse): more than 22.6 million exposed instances potentially vulnerable;
  • Bitsight: among instances with an identifiable version, about one third run a branch covered by the release (8.2-8.5) and two thirds older branches; the most common branch is 7.4, with more than 2 million observations;
  • Recorded Future, citing Modat, reports about 79% of services with a readable version on unsupported branches; on VirusTotal about 758,000 IPs on end-of-life branches against about 272,000 on supported ones.

The figures are not comparable with each other, but they point the same way: most exposed PHP that declares its version runs on branches that will not receive an official fix.

What changes for those who have to act

  • The realistic risk is the standard configuration. If an exploit works on a specific profile, the most common profiles (popular Docker images, hosting with mod_php) are the first targets. Standard installations should be updated first.
  • End-of-life branches need migrating. There is no release for 8.1 and older: move to a supported branch or check whether your vendor offers a backport.
  • Mitigations remain partial. CrowdStrike points out that disabling session upload progress does not cover every vector; it also advises disabling uploads where they are not needed, limiting request size and running each application under a separate least-privilege account.
  • Logs should be checked retroactively, from at least 17 October: web server processes spawning shells, new PHP files in web roots, unusual outbound connections. If there is a compromise, ReliaQuest recommends rotating credentials, tokens and keys present on the server.
  • Unverified proofs of concept should not be run. At least one author has already invalidated the theory behind their own, and code in circulation may contain malware.

What we think

In a case that changes by the hour, source quality matters as much as speed. An update retracted after two days spread far more widely than its retraction, and those who repeated it without checking again are now telling a story the source no longer supports. For decision-makers little changes: php2shell’s priority does not depend on whether it is exploited by an AI agent or a person. The figure that really matters is another one: most installations that declare their version run branches with no fix. The work remains knowing where PHP runs, updating or migrating, and looking for traces in the logs, without waiting for the KEV listing.

What to watch

  • Confirmed compromises from incident response on real systems, as distinct from honeypot results.
  • The addition of the two CVEs to CISA’s KEV catalogue.
  • Second-stage payloads and exploits adapted to popular applications.
  • Backports for out-of-support branches from distributions and vendors.

Sources

Need support?Under attack?Service Status
Need support?Under attack?Service Status