Independent Reporting · Not Legal or Security Advice · Verify With the Breached Company · Editorial Policy
Team monitoring screens in a security control room

Is PHP2Shell Being Exploited? CISA Says Not Yet, watchTowr Sees Attempts

by

Is PHP2Shell being exploited? A day after PHP patched the two flaws on Wednesday, Oct. 21, the honest answer is that people are trying, and nobody has shown that it worked. Several security companies report attack traffic aimed at CVE-2026-109618 and CVE-2026-109619. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says it has not seen exploitation, and the bugs are not on its official list of exploited flaws. This explainer sets out who said what, so you can tell when the PHP2Shell exploited label is earned.

Where it stands: In fresh copies of the CISA and NVD records pulled early on Oct. 22 (the NVD records carry a retrieval stamp of 04:02 UTC), CISA’s Known Exploited Vulnerabilities (KEV) feed was still on catalog 2026.10.21 and did not list either CVE. Both NVD records still showed CISA’s exploitation assessment as “none”, the value entered at 14:34 UTC on Oct. 21.

Is PHP2Shell exploited in the wild? The short answer

Attempts, yes; confirmed compromises, not yet. Exploitation attempts against PHP2Shell are being reported by several firms, but no confirmed successful compromise had been published as of early Oct. 22.

Those are different claims. An exploitation attempt is attack traffic aimed at a bug, which can be caught by a honeypot (a decoy server set up to attract attackers) or a firewall. Exploitation in the sense CISA tracks means there is evidence an attack actually worked against a real system. When coverage says “actively exploited”, check which of the two it means.

What did CISA say about PHP2Shell exploitation?

CISA’s Oct. 21 alert said the agency “has not observed exploitation of these vulnerabilities as of the time of publication”, while warning that they pose a risk if left unpatched. Its remediation advice was blunt, telling organizations that cannot update, or that run PHP 8.1 or earlier, to take PHP-based systems offline until they are fixed.

Two machine-readable records back that up. On the NVD entries for both CVEs, CISA’s SSVC field (a scoring system CISA uses to rate how urgently a flaw needs action) records exploitation as “none”. And the KEV catalog, CISA’s list of vulnerabilities it knows have been used in attacks, did not include either CVE in version 2026.10.21, which was still current on Oct. 22. That version was published at 14:04 UTC, shortly before NVD posted the first PHP2Shell record. watchTowr’s own FAQ shows the same status: “CISA KEV Not listed.”

Absence from KEV is not a clean bill of health. CISA adds entries when it has evidence, and Tenable points out that the catalog already holds three vulnerabilities in PHP itself, so PHP bugs do land there when evidence arrives.

What did watchTowr, Cloudflare and others report?

The firms that run sensors and firewalls describe attack traffic, with wording that ranges from cautious to alarmed.

Source What it said Strength of claim
CISA (alert, NVD, KEV) Has not observed exploitation; not in KEV None observed
PHP security team No functional exploits found among PoCs at release None verified
Tenable Circulating code not verified to work Unverified
watchTowr Exploitation attempts on both CVEs; none successful, per SecurityWeek Attempts
Cloudflare Attack traffic against customers, payloads mutating Attempts
Patchstack Exploitation attempts, per SecurityWeek Attempts
Chainguard Honeypots trapped IPs from China and Russia, per The Register Attempts
Vercel, Fastly Working public exploits; attacks before disclosure Vendor claim

watchTowr wrote that it “is observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619”, and its key-facts box labels the bugs as exploited in the wild. Its FAQ says the observations came from its Attacker Eye honeypot network. SecurityWeek, however, reported that watchTowr had seen the first in-the-wild attempts around the time patches landed but had not observed successful ones, quoting threat intelligence head Jake Knott: “Whilst nobody has been successful to date, we don’t expect that will last long.”

Cloudflare said it “observed attack traffic targeting our customers” after the bug leaked ahead of the release date, and that attackers kept altering their payloads to try to slip past its rules. BleepingComputer reported that Cloudflare CTO Dane Knecht confirmed early attacks before the patches were out.

Vercel went further, saying “Working public exploits are already available”, and Fastly wrote that there is “evidence of active attacks in-the-wild pre-disclosure”. Neither published a named victim.

Do working PHP2Shell exploits exist?

That is where sources split. The PHP security team says it inspected the proof-of-concept code (PoCs, demonstration exploits) that appeared after the leak and “did not identify any functional exploits at the time of release/public disclosure.” Tenable says code claiming to work is circulating but that it had not verified any of it against either CVE.

CERT-EU, the EU institutions’ security team, reads the same situation more darkly: with PoCs circulating, it says, the likelihood “that attackers are already exploiting the vulnerabilities” goes up. Tenable adds a practical warning for curious administrators: “Unverified exploit code is sometimes laced with malware, so treat it with caution.”

Why the label matters for your patching

For most site owners, the exploited-or-not debate should not change the decision. PHP’s advisory says “There are no complete mitigations, updating is the only safe choice”, and each supported branch already has a fixed build waiting (8.3.36 is the one for anyone on the 8.3 branch, for instance). Our PHP2Shell patch guide for WordPress and hosting covers which hosts have updated.

Where the label matters is triage inside larger organizations that rank their patch queues by confirmed exploitation. Until CISA adds an entry, the most precise wording is the one CISA and SecurityWeek support: attempts are being reported, success has not been shown.

What to watch next

  • A KEV entry for CVE-2026-109618 or CVE-2026-109619 would be the clearest official signal that exploitation is confirmed.
  • A named victim or incident report from a host, company or government. None has been published; the government outages so far were precautionary, as covered in why governments took websites offline.
  • Your own logs. If you could not patch quickly, check web server and PHP error logs for unusual crashes, and treat any sign of unknown processes or files as a possible compromise.

How the bug details got out early is its own story, told in our PHP2Shell leak timeline. For reference, NVD scores CVE-2026-109618 at 9.8 on CVSS 3.1, while CISA’s own exploitation field on that record still read “none”.

Frequently Asked Questions

Is PHP2Shell being actively exploited?

Exploitation attempts are being reported by watchTowr, Cloudflare, Patchstack and others, but no confirmed successful compromise had been published as of early October 22. CISA said on October 21 that it had not observed exploitation, and neither CVE was in its KEV catalog.

Is PHP2Shell in the CISA KEV catalog?

No. Data Breach Radar re-checked CISA’s KEV feed early on October 22, and the current catalog, version 2026.10.21, did not include CVE-2026-109618 or CVE-2026-109619. KEV entries are added when CISA has evidence of exploitation, so this can change.

What is the difference between an exploitation attempt and exploitation?

An attempt is attack traffic aimed at the bug, often caught by honeypots or firewalls. Exploitation in the stronger sense means an attack worked and an attacker gained access to a real system. For PHP2Shell, reports so far describe attempts.

Are there working PHP2Shell exploits in public?

Sources disagree. Vercel says working public exploits are available, while Tenable says it had not verified that any circulating code works and warns that such code is sometimes laced with malware. PHP found no functional exploits among the PoCs it inspected at release.

What should I do if I cannot patch PHP right away?

CISA says organizations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline until they are patched. PHP itself says there are no complete mitigations and updating is the only safe choice.

Sources

This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.

Owed money from a settlement? Check what is open at OpenClassActions.com. Caring for someone with dementia? Find practical guides at HelpDementia.com. Working out a skin routine? Evidence-based answers at AcneAdvocate.com. Forgot the name of a movie? Identify it at FindThisMovie.com.

We use cookies to run this site, measure how it’s used, and show ads. Choose “Essentials only” to limit cookies to what the site needs to work. Privacy Policy. Cookie Policy.