Three remote code execution flaws, one week: PHP, Brotli and WordPress

In the second half of October 2026, three separate remote code execution flaws surfaced within a week in components that sit under a large share of the internet: the PHP runtime, the Brotli compression library bundled into Node.js, .NET and Python, and WordPress core.

Each one lets an attacker run code on the server. For at least 2/3, exploitation attempts were recorded before the fix was public. The applications built on these components were never touched, and that is what makes the case worth a closer look.

 

What happened in October 2026?

Within a single week, researchers and vendors disclosed three unrelated remote code execution flaws, each rated critical, each in a component that thousands of applications depend on. All three were found in dependencies and shared libraries, never in the applications built on top of them.

1. The PHP runtime (CVE-2026-109618, CVE-2026-109619).
   On October 21 the PHP project shipped emergency fixes for two flaws that allow unauthenticated remote code execution, rated CVSS 9.2 and nicknamed PHP2Shell. These reach almost any server that uses PHP to handle web requests. Amazon Threat Intelligence recorded exploitation attempts on October 17, four days before the patches existed, and researchers soon published working exploits, one of which defeats ASLR on x86-64 servers.
   
   Two days after the fixes, PHP disclosed a third flaw in the same session-handling surface, CVE-2026-115560.
   
   
2. The Brotli decoder (CVE-2026-111497, nicknamed Broccoli2Shell).
   An out-of-bounds write in Google's Brotli decompression library, also rated CVSS 9.2. Brotli decompresses Content-Encoding: br automatically, so the flaw reaches any application that decodes attacker-controlled compressed data: Node.js, .NET, Python, Bun, Envoy, Istio and more, most of them with no mention of Brotli in their own code.
   
   The fix was committed to the Brotli source on February 27, 2026, then sat unreleased and publicly readable for eight months, and exploit traffic carrying a public proof-of-concept has been confirmed in the wild.
   
   
3. WordPress core (Click2Shell).
   A chain fixed in WordPress 7.1.1 that forces an administrator's browser to install a theme from the official directory and, combined with a flaw in that theme, executes arbitrary PHP on the server.

 

Are we affected, and where? How fast can that be answered?

The moment a disclosure like this lands, security and engineering drop what they were doing to answer one question: does the affected component run anywhere in the estate, and where exactly. While that question is open, the attack surface is exposed to something already under attack, and every hour it stays open favors the attacker.

Answering from memory does not scale. A single PHP service pulls in:

• a runtime,
• extensions,
• framework dependencies
• and a long tail of transitive packages.

 

Brotli shows why: the vulnerable code arrived bundled several layers down, invisible to anyone reading the application's own manifest. Searching repositories by hand during an active exploitation window is how exposed components get missed.

What answers it in minutes is a current software bill of materials: a per-application inventory of every component in the build, direct and transitive. With one on hand, "are we affected" turns from an investigation into a lookup.

 

Which part of the testing stack answers a component CVE?

Three analysis types examine an application from three angles, and the October wave sits squarely in the third.

 

Analysis	Question it answers
SAST	Where might in-house code be unsafe?
DAST	What surfaces in the running application?
SCA	Which components in the build carry known vulnerabilities?

 

DerScanner SCA builds the SBOM and flags the components in it that have advisories against them. Results are grouped by component and version, label direct and transitive dependencies, and carry finding status and comments, so a review ends in decisions rather than a flat list. SBOM input follows the CycloneDX standard, and PHP composition is generated from composer.json and composer.lock.

The PHP case makes one distinction concrete. A composer.lock file lists application dependencies, while the PHP interpreter installed on the server is a separate component with its own advisories. A real inventory accounts for both, which is why a sound evaluation starts by confirming how the deployed runtime shows up in the scan input and what sits outside it.

 

Why does running the scan once fall short?

A scan run once, during an incident, closes one advisory. The components underneath an application keep moving. New CVEs get disclosed against dependencies that were clean last quarter, and the window between disclosure and exploitation has shrunk to days, or to nothing at all, as the PHP timeline showed when attacks preceded the patch. Composition analysis delivers its value when it runs on every build and release, so the component inventory is already current the next time an advisory arrives, and nobody has to reconstruct it under pressure.

A completed scan reflects the build as it stood on the day it ran. Keeping the inventory accurate means re-scanning on the schedule the release process already follows, well before the next headline forces the question.

 

How to put this to work on one application

The practical first step is narrow. Take one business-critical application, generate its SBOM, and run composition analysis against it next to the SAST and DAST checks already in place. Agree the scope, run the scan, then review the findings with the engineers who own the dependencies and the people who deploy, so each priority item leaves the room with a decision and an owner. One application is enough to see where the blind spots are and how fast the next "are we affected" gets answered.

Related reading: How DerScanner generates an SBOM and finds vulnerable components.

 

Ready to see what runs underneath the applications?

DerScanner builds the SBOM, runs composition analysis against it, and keeps the component inventory current across every release. Book a demo to walk through it on a real application, or request a proof of concept and run it on a business-critical build.