PHP2Shell campaign tracker: exploitation status, actors and confidence levels

PHP2Shell exploitation is being reported faster than it can be verified, and defenders need to know which claims are confirmed, which are reported and which are one vendor's assessment. This tracker follows the campaign activity around CVE-2026-109618 and CVE-2026-109619, the two critical flaws in the PHP interpreter fixed on 21 October 2026. It records each claim with its source and a confidence label, so threat intelligence, SOC and vulnerability teams can brief leaders without overstating or understating the threat. It does not repeat the patching, mitigation and credential rotation guidance, which lives in the PHP2Shell guide. No exploitation mechanics are included.

Status as of 2 November 2026: both CVEs are in the CISA Known Exploited Vulnerabilities catalogue (added 26 October, federal due date 29 October, forensic triage flagged). The PHP project has published nothing new since 26 October. Working exploits and successful in-the-wild exploitation have been reported by several researchers and outlets. One suspected state-linked scanning campaign and one criminal extortion operator holding PHP2Shell tooling have been described by vendors. No vendor or government source we read has named a confirmed victim compromised through PHP2Shell.

Key takeaways

• Exploitation is confirmed by CISA, not just rumoured. KEV inclusion on 26 October means CISA holds evidence of active exploitation. Treat every unpatched internet-facing PHP host as exposed and investigate, not only patch, back to 17 October.
• The volume numbers are attempts, not compromises. Cloudflare's millions of attempts and the multi-million exposure counts describe scanning and reachable hosts. Recorded Future says neither exposure scan counts confirmed vulnerable hosts.
• Actor attribution is moderate at best. Cyfirma, as reported by Security Affairs, links one scanning campaign to the Lazarus family with moderate confidence and says a Korean-speaking criminal group would fit the same facts. Brief it as a possibility, not a finding.
• Early reports have already been withdrawn. GovInfoSecurity reported that two security firms retracted exploitation claims, and Recorded Future says it had not validated the public proofs of concept. Some public exploit code is reported to be fake and carry malware.
• The follow-on risk is credentials on shared hosting. SOCRadar's extortion case did not use PHP2Shell for its first wave, but it shows exactly what happens after a PHP foothold: a stored SSH key and a reused database password reached other sites on the same host.

How to read this tracker

Every claim carries one of four labels. Use the label when you repeat the claim in a briefing, and do not upgrade it.

Where sources disagree, the primary source wins. Two examples on this page: GovInfoSecurity dates the patches to 22 October, but php.net shows 21 October; Security Affairs cites BOD 22-01 for the KEV deadline, but the KEV record itself cites BOD 26-04. This page uses php.net and the KEV data in both cases. For how KEV status should drive priority outside US federal agencies, see the CISA KEV Catalogue Guide.

Exploitation status timeline

The window that matters for investigation starts on 17 October, not on the patch date. Recorded Future advises reviewing logs from 20 October or earlier; the Amazon report pushes that back three days.

Exploit maturity: what is actually working

Exploit maturity drives urgency more than headline volume. The picture moved quickly from leaked details to working code in under a week, and several early claims did not hold.

What this means for defenders: by the end of October, competent researchers could reliably exploit at least some x86-64 builds, and CISA had evidence of exploitation. Configuration still matters: the PHP project and Recorded Future both note that success depends on build, extensions and memory layout, which is why many hosts will be harder targets. That is a reason to expect uneven compromise, not a reason to defer patching. Never run a public proof of concept on a production or corporate network to "test" exposure: use version and configuration checks instead.

Actors and campaigns

Two named activity clusters have been described in detail. Neither has a confirmed PHP2Shell victim in the sources read.

Suspected North Korea-linked scanning campaign (Cyfirma)

All points below are Cyfirma's assessment as reported by Security Affairs on 26 and 27 October.

• Attribution: moderate confidence link to the Lazarus family, based on language, operating style and past PHP web shell habits. Cyfirma notes a Korean-speaking criminal group without state backing would fit the same facts. Confidence that the campaign exists is high. Background on the group is in the Lazarus Group Threat Actor Profile and the North Korea Cyber Operations Guide.
• Infrastructure: two handles, active since March 2026, coordinating in a closed I2P channel; 21 compromised machines used as scan nodes, some of which may belong to victims; Cyfirma published defanged scan, source and staging addresses.
• Targeting: 216 possibly vulnerable hosts identified by 24 October, with about one third checked when the conversation was captured. Priority sectors were government and banks, then logistics, ports, airports and aviation, manufacturing and online trading platforms. Named countries include the US, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the UAE, Saudi Arabia and the EU.
• Behaviour: slow, low-volume scanning with rotating machines, so rate-based alerts are unlikely to fire; hosts showing a fixed version or heavy filtering were dropped, while hosts still advertising older PHP were kept. Reported activity included web shell tooling and upload progress session poisoning attempts.
• Tooling: a local AI model reportedly ranks public exploit repositories, with manual lab testing; the group does not appear to write new exploits.
• Victims: none named; Cyfirma has not seen the full target list and researchers have not confirmed large-scale compromises.

Extortion operator with PHP2Shell tooling (SOCRadar)

All points below are SOCRadar's assessment from an exposed staging server, published 27 October.

• Prior activity, not PHP2Shell: an extortion wave on 9 to 11 October against a Japanese real estate services company and about 20 related domains on the same shared hosting used existing web shell access. SOCRadar states this wave did not rely on PHP2Shell and the server does not show how initial access was gained.
• PHP2Shell added later: a weaponised copy of a PHP2Shell reproducer package appeared on 21 October, alongside mass scans of Hong Kong and Taiwan ranges. SOCRadar found no saved output showing successful PHP2Shell exploitation of a live target.
• Tactics seen: homepage and admin panel defacement with a countdown (T1491.002), a cron job that rewrote .htaccess every minute to restore ransom pages (T1053.003), sweeping home directories for backups (T1490), and pressure on customers through bulk email.
• Identity lesson: a stored SSH private key let the operator log into other accounts on the same hosting provider (T1552.004, T1021.004), and one database password was reused across several victim sites. See the SSH Key Management Guide.
• Attribution: SOCRadar presents language and handle details only as investigative leads, not a confirmed identity. This page does not repeat them.

Exposure figures

The end-of-life share is the figure to take to leadership: it means a large part of the exposed population cannot take the 21 October releases at all. The Unsupported PHP versions guide covers finding and retiring those runtimes.

Intelligence requirements and what to watch next

Set these as standing questions for the threat intelligence function until the campaign settles. Each has the source most likely to answer it first.

1. Does KEV change ransomware use from "Unknown" to "Known"? Watch the KEV JSON on GitHub (cisagov/kev-data). A change would raise priority for any remaining hosts and should trigger a fresh hunt.
2. When does PHP publish the CVE-2026-115560 advisory and the next bugfix releases? Watch php.net and the php-src GitHub security advisories. Until then, keep session.upload_progress.enabled=0 where you do not use it.
3. Do confirmed victims emerge? Watch for incident disclosures, regulator notices and vendor incident response reports naming PHP2Shell as the initial access route. Until one does, describe compromise as "reported" not "confirmed".
4. Does attribution firm up? Watch for government advisories naming an actor, which would outrank vendor attribution.
5. Does exploitation spread to ARM64 or other SAPIs? Today's vendor findings centre on x86-64 and mod_php. A change would widen the urgent patch set.
6. Does your hosting or managed platform provider confirm patch and restart times? Those dates bound your own investigation window.

A short internal report against these questions, refreshed weekly, is more useful than forwarding every article. The Threat Intelligence Report Template gives a structure, and the Threat Intelligence Guide covers sourcing and confidence language in general.

Turning the tracker into action

Use the status to set priority, then hand the work to the playbooks that already exist.

1. Confirm the patch state of every internet-facing PHP host. Include end-of-life branches, vendor builds (Security Affairs lists cPanel EasyApache, CloudLinux, TuxCare and Plesk as shipping their own) and container images. The step-by-step checks are in the PHP2Shell guide.
2. Treat KEV forensic triage as a requirement, not a suggestion. For hosts unpatched at any point after 17 October, collect logs and snapshots and hunt before declaring them clean.
3. Hunt for the behaviours reported in these campaigns. New PHP files in upload directories, cron jobs for the web user, .htaccess rewrites, defaced pages and web worker child processes. Use the PHP web shells guide and the Web Shell Response Playbook.
4. Do not rely on rate-based alerting. Cyfirma describes deliberately slow scanning. Alert on version probing of PHP hosts and on any successful request followed by unusual process or file activity.
5. Rotate credentials the worker could read on any suspected host. Prioritise SSH keys and shared database passwords on shared hosting, as SOCRadar's case shows. Follow the Leaked Credential Response Playbook.
6. Block known infrastructure as a supplement. Load defanged indicators from vendor reports into blocklists and hunts, accepting that scan nodes may be compromised third-party machines.
7. Brief with labels. Leadership summaries should say "confirmed by CISA" for exploitation and "vendor assessment, moderate confidence" for attribution.

Detection and measurement

Metrics that show the response is keeping pace:

• Percentage of internet-facing PHP hosts on fixed builds or vendor backports with workers restarted.
• Percentage of hosts unpatched after 17 October with forensic triage completed.
• Number of end-of-life PHP hosts still internet-facing, tracked weekly to zero.
• Time from a KEV or php.net change to an internal briefing update (target under one working day).
• Percentage of hosting and managed providers that have confirmed patch and restart times in writing.
• Credentials rotated and verified on suspected hosts, against those the worker could read.

Common failure patterns

• Treating attempt counts as compromise counts. Millions of attempts and five-million-host exposure figures make good headlines but are not evidence of breach. Report them as what they are.
• Upgrading attribution in the retelling. "Moderate confidence Lazarus-family link, alternative explanations possible" becomes "North Korea is exploiting PHP" by the third email. Keep the label attached.
• Testing with a public proof of concept. Some are reported to be fake or malicious, and many rely on techniques that were invalidated. Version and configuration checks are safer and more accurate.
• Starting the hunt at the patch date. Amazon's reported 17 October activity and the pre-disclosure leak mean the window opens before 21 October.
• Forgetting shared hosting credentials. SOCRadar's case shows a stored SSH key and a reused database password doing more damage than the initial foothold. The GoDaddy Managed WordPress Breach 2021 is the larger-scale version of credentials held where one foothold can read them.
• Waiting for a confirmed victim before acting. KEV status already establishes exploitation. A named victim would add detail, not change the priority.

Framework mapping

Practitioner checklist

• Check the KEV JSON and php.net at least weekly and update the dated status line in your internal briefing.
• Label every external claim as confirmed by CISA, confirmed by PHP, vendor assessment or reported by outlet.
• Confirm every internet-facing PHP host is on a fixed build or vendor backport with workers restarted.
• Run forensic triage on any host unpatched at any point from 17 October 2026.
• Hunt for web shells in upload directories, web user cron jobs, .htaccess rewrites and defacement.
• Rotate SSH keys and database passwords shared across sites on any suspected shared host.
• Load defanged vendor indicators into hunts and blocklists, treating them as supplementary.
• Never run public proof-of-concept code against your own systems to test exposure.
• Schedule end-of-life PHP replacement, starting with internet-facing hosts and PHP 8.2 before 31 December 2026.

Standards and references

• CISA: Known Exploited Vulnerabilities Catalog
• PHP: News, security releases and advisories (October 2026)
• Recorded Future: PHP2Shell Exploitation, Two Critical PHP Flaws Explained
• SOCRadar: PHP2Shell Weaponized After Japanese Real Estate Extortion
• Security Affairs: PHP2Shell, suspected North Korean campaign targets 216 vulnerable PHP hosts
• GovInfoSecurity: Honeypots Now Recording in-the-Wild PHP2Shell Exploits
• The Next Web: Cloudflare sees millions of attempts to exploit critical PHP flaws
• BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches

Related NHI Mgmt Group resources: PHP2Shell · CISA KEV Catalogue Guide · Web Shell Response Playbook · Lazarus Group Threat Actor Profile · Unsupported PHP versions