CISA Adds PHP2Shell Flaws to Exploited List as Attacks Succeed

The US Cybersecurity and Infrastructure Security Agency (CISA) on Monday, October 26, added both PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog. It ordered federal civilian agencies to fix them by October 29, according to The Register. The listing means the flaws have moved from a scanning problem to a confirmed attack problem for any business running unpatched PHP.

What is PHP2Shell and why does it matter?

PHP2Shell is the collective name for two critical flaws, CVE-2026-109618 and CVE-2026-109619. The Register reports that both are rated 9.2 on the CVSS scale and can be exploited without authentication to run code on vulnerable PHP servers.

BleepingComputer adds a qualifier: attackers need no privileges, but the attacks are high-complexity. That helps explain why early exploitation attempts mostly failed. It does not make the bugs safe to leave open.

The PHP security team patched the flaws on Wednesday, October 21, one day after asking administrators to prepare for the update. PHP sits behind a large share of websites, customer portals and internal tools, so the exposure is wide even if each individual exploit is demanding.

How did exploitation progress before the patch?

Attackers were early. Amazon Threat Intelligence researchers spotted attempts four days before the patches were released, and The Register puts the first sighting at October 17. That is four days before public disclosure.

The PHP team said details of the bugs, including CVE IDs and mitigation advice given to some critical infrastructure providers, leaked online before release. Some proof-of-concept exploits also appeared. The team said none of those early exploits were functional.

Cloudflare, Hadrian, watchTowr, Previdian and Patchstack all saw attempts before disclosure. They judged them unsuccessful, BleepingComputer reports. For several days the evidence pointed to noise: scanning and fingerprinting rather than compromise.

That changed on October 24. Perplexity security researcher Adel Karimi recorded 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php. The traffic came from two IP addresses and used memory exhaustion and disclosure to reach remote code execution. The attackers then tried to contact external servers using PHP, curl and wget.

Marcus Hutchins of Expel, who has been tracking alleged exploitation reports, called it the highest-quality confirmation he had seen. Karimi himself added a limit. The chain was shown on a deliberately favourable single-worker mod_php profile and is not a measure of reliability on other worker counts, PHP builds or applications.

What is confirmed, and what is still disputed?

Reports of government breaches are where the evidence gets thinner. The table separates what several sources support from what rests on one vendor or has been withdrawn.

On the European case, Palo Alto Networks' Unit 42 said it was retracting its earlier assessment that the post-compromise activity involved PHP2Shell. A spokesperson told The Hacker News the researchers saw an attack in the context of a vulnerable PHP application. The earlier version of the story had said attackers reached MFA secrets and password hashes with signs of agentic AI use. Treat that framing as unverified.

On the US case, Cybernews reports that security firm Dream said suspected China-linked attackers chained the two PHP2Shell flaws with a Linux kernel bug called "Fragnesia" to gain root on vulnerable firewalls without authentication. Dream, as reported, did not attribute the activity to a specific threat actor. It based its China-linked belief on language prompts, timestamps and geographic targeting.

Dream also reported installations of Claude Code and offensive tooling configured with DeepSeek and Kimi models. Those details come from one vendor's account and I could not find independent confirmation. They fit a wider pattern of attackers using AI to speed up exploitation, but they do not show who is behind the activity.

How big is the exposed footprint?

Cybernews reported that new data showed 32.5 million PHP services still running susceptible versions, 10.3 million of them in the US. The article does not make clear who produced the data or how it counted, so read it as an order-of-magnitude signal. Many of those services will be behind configurations that make the high-complexity exploit harder.

The shape of the timeline is the real lesson. Exploitation attempts began before disclosure, honeypots confirmed success three days after the patch, and CISA's listing came five days after the patch. A business that waits for a KEV entry before acting has already lost most of that window.

What should security teams do now?

1. Patch to the October 21 releases. Prioritise internet-facing servers, then internal ones. The PHP team's fixes are the only mitigation the sources confirm.
2. Inventory where PHP runs. Dream's report points to PHP inside firewall products. Ask vendors whether their appliances embed PHP and when fixes ship, because you cannot patch those yourself.
3. Look at Apache mod_php first. The confirmed successful attacks hit that setup. Karimi's caveat means other setups may be harder to exploit, not that they are safe.
4. Hunt for outbound calls from web servers. The honeypot attackers tried to reach external servers with PHP, curl and wget. Unexpected egress from a web tier is a cheap signal to alert on. CISA has also published a Sigma detection rule for exploitation attempts, shared on Friday.
5. Treat the October 17 to 21 window as suspect. If a server was exposed and unpatched during those days, review logs for it instead of assuming the early attempts all failed.

What else landed on the KEV list this week?

PHP2Shell was not the only entry. On October 27, CISA added two more flaws: CVE-2026-48356, an Adobe Commerce and Magento file upload flaw, and CVE-2026-111497, a Google Brotli flaw. Security News reports the Brotli bug, known as Node2Shell, is an out-of-bounds write that attackers are already hitting with live exploit traffic against Node.js servers.

For teams running web stacks on PHP, Node.js or Magento, that is three web-facing remote code execution risks in a single week. The practical constraint is capacity, not awareness.

What to watch next

Three things will decide how serious this becomes. The first is whether exploit reliability improves beyond the favourable honeypot setup, which would turn a high-complexity bug into a mass-exploitation one. The second is whether Dream's findings are corroborated by a second firm or by CISA. The third is whether vendors that embed PHP publish their own advisories. CISA has said little about ongoing attacks so far, so more detail from the agency or from incident responders would sharpen the picture.