PHP2Shell Exploitation, Node2Shell Brotli RCE, And Mimori Ransomware Claims

This episode breaks down:

• PHP2Shell one week later: working shells, a KEV listing, and exploit noise
• Node2Shell, a Brotli flaw whose public fix went unreleased for eight months
• Mimori ransomware claims against OpenText and AVEVA, and what's actually confirmed

Plus Bishop Fox research on which PHP configurations turn PHP2Shell into remote code execution, and what Claude revealed about its own sandbox when asked.

PHP2Shell Exploitation Update: CISA KEV Listing, Working Shells, and Attacks Before Disclosure

For background on how PHP2Shell works, which versions are affected, and how the disclosure broke, see Episode 40.

PHP2Shell exploitation moved from probes to confirmed attacks in the week after disclosure. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 and CVE-2026-109619, the two critical PHP engine flaws known as PHP2Shell, to its Known Exploited Vulnerabilities (KEV) catalog on October 26, 2026. The listing followed reports of working shells on honeypot servers, and it gave federal civilian agencies until October 29 to remediate.

When did PHP2Shell exploitation actually begin? Earlier than the disclosure. Amazon's MadPot honeypots logged a PHP2Shell exploitation attempt on October 17, 2026, four days before PHP released fixes and three days before details leaked online. For vulnerability intelligence teams, disclosure day can no longer be treated as day zero. Someone may already be testing a flaw by the time the advisory lands.

Is PHP2Shell on the CISA KEV catalog? Yes. CISA added both CVEs on October 26, 2026, after a researcher confirmed successful remote code execution against honeypots on October 24, with 35 shells launched from two IP addresses. CISA counts both attempted and successful exploitation as "active exploitation" for KEV purposes, and it also published a SIGMA detection rule for PHP2Shell exploitation attempts. Although the October 29 deadline applies only to federal agencies, it is a reasonable benchmark for any organization running internet-facing PHP.

Why do so many public PHP2Shell exploits fail? Most of what circulated in the first days was noise. In the hours between the leak and the official patch, scanners and proof-of-concept scripts flooded public repositories, many of them AI-generated, many not targeting the actual vulnerability, and some built to compromise whoever ran them. After the patch shipped, cleaner-looking code appeared, but it carried borrowed confidence it hadn't earned. Real exploitation depends heavily on the server API, opcache, error display, memory settings, and even CPU architecture, so an exploit that works on a stock container image often has to be re-tuned for a production application.

How do you find every PHP installation affected by PHP2Shell? Look past web servers. PHP often arrives as a dependency of something else, and many of those places don't report a version externally:

• Vendor appliances, including Palo Alto Networks PAN-OS and Panorama, which Palo Alto listed as affected.
• Container images built on PHP base images, which stay vulnerable until rebuilt and redeployed.
• Hosting control panels and managed hosting environments.
• Applications whose installers require a minimum PHP version, such as WordPress plugins and line-of-business tools.

Distribution packages add another layer of difficulty. Distros backport fixes under older version numbers, and package repositories can lag behind PHP's own release, so routine OS updates may not deliver the fix on day one. Confirm patch status against package changelogs or vendor advisories, and track what runs inside each asset with a software bill of materials.

When should a PHP2Shell patch become an incident response? When a host was exposed and unpatched while exploitation was active. Beyond code execution, PHP2Shell can leak PHP worker memory, which may hold passwords, API tokens, and keys from other requests. For internet-facing PHP that stayed unpatched after October 17, review hosts for compromise and rotate credentials the application handled, rather than closing the ticket at the upgrade.

Mitigation: Patch every PHP runtime to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply vendor backports, then restart all workers and rebuild container images. Prioritize Apache mod_php and internet-facing hosts, validate the fix by changelog or advisory instead of by version string, and pull in vendor patches for appliances that embed PHP. Where patching must wait, apply PHP's interim hardening measures and CISA's SIGMA rule, and treat exposed, unpatched hosts as candidates for investigation.

Sources: The Hacker News, SecurityWeek

CVE-2026-111497: Node2Shell Brotli Out-of-Bounds Write in Node.js, .NET, and Python

Node2Shell, also called HTTP2Shell and Broccoli2Shell, is CVE-2026-111497, an out-of-bounds write in Google's Brotli decompression library, versions 1.0.3 through 1.2.0. Because Node.js bundles its own copy of Brotli, a crafted compressed payload can crash a Node.js process, leak its memory, or run code. Google committed the fix to the public google/brotli repository on February 27, 2026, but shipped no release or advisory for eight months. Fixes arrived October 21 in Brotli 1.0.10, 1.1.1, and 1.2.1 and Node.js 26.12.1, 24.22.1, and 22.23.4; end-of-life Node.js lines 20.x, 23.x, and 25.x will not be fixed. Microsoft issued emergency .NET patches, Bun fixed it in 1.4.4, and Python packages and VMware products are also affected.

Exposure is narrower than the name suggests. Only services that decompress Brotli data an attacker controls are at risk, such as fetch() calls to user-supplied URLs and Express 5 apps using body-parser 2.x, which decode request bodies sent with Content-Encoding: br. Imperva demonstrated code execution on the official Node.js 24.22.0 arm64 image after multiple attempts. A scanner called node2shell-check mapped which hosts decompress Brotli, and exploit traffic using the public proof of concept followed on October 26. CISA added the flaw to KEV on October 27 with a November 10 deadline for federal agencies. Inventory bundled copies of Brotli, not just Node.js, rebuild container images, and block Brotli-encoded requests at the proxy until patched.

Source: Help Net Security

Mimori Ransomware Claims OpenText and AVEVA: What's Confirmed So Far

Mimori, a ransomware and extortion group first seen in October 2026, listed Canadian software company OpenText and UK industrial software maker AVEVA on its leak site on October 20. It claimed 94,306 OpenText files and set an October 29 publication date. Neither company has publicly confirmed an incident, the group initially posted no samples, and its leak site has been intermittently offline. Hudson Rock infostealer data ties about 21,000 passwords to OpenText and about 16,400 to AVEVA, which points to stolen credentials as a possible entry point, though nothing confirms it.

On October 26, the Atos Threat Research Center published an analysis of more than 3,100 files from Mimori's exposed operations workspace, including tools, internal notes, execution logs, and a draft ransom note. The material shows a playbook aimed at Active Directory, VMware vCenter and ESXi, and backup systems, with a critical vCenter flaw, CVE-2026-59310, playing a major role, and tooling built to shut down domain controller virtual machines from the hypervisor so they can't restart. Atos found no confirmed links to established groups and no Mimori-specific encryptor, and trackers disagree on how many victims the group has claimed, so validate leak-site data before it reaches a customer brief.

Source: Red Tiger Security