Two of this month's most serious vulnerabilities share an awkward feature: neither lives in a product you bought. PHP2Shell is in the PHP runtime. The Brotli flaw is in a compression library. Both sit inside other software, often several layers down, and both can leave a patch report showing green while vulnerable copies keep running.
Two flaws, one blind spot
On 26 October, CISA added the two PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalogue, after successful exploitation was confirmed. Both are memory corruption bugs that can allow unauthenticated code execution on a web server. PHP fixed them on 21 October, and the NCSC's alert opens with an instruction that says a lot: find all your PHP installations first.
The same week, the Brotli decoder flaw, CVE-2026-111497, produced fixes for Node.js, Python, .NET and Google's library itself. The advisories carry the same warning in different words: updating the system library does not fix applications that bundle their own copy. Even PHP's Windows builds needed a second patch for it.
Neither of these is exotic. They are what modern software is made of.
Why the patch report stays green
Most patch reporting measures the operating system and the applications installed on it. Did the server get this month's updates? Is the browser current? Those are good questions, and they are the wrong ones for a library flaw, because:
- Applications bring their own copies. A self-contained .NET app, a desktop tool built on Node, or a vendor appliance ships its own runtime. The host update never touches it.
- Containers freeze a moment in time. An image built last spring carries last spring's libraries until somebody rebuilds it.
- Vendors embed open source and patch on their own schedule. NCSC-NL had to publish an inventory of products that bundle PHP, because customers had no other way to know.
- Developers choose libraries in code. Whether an app decodes Brotli is a line in a source file, not a setting anyone in operations can see.
So the dashboard reports 100% compliance and is telling the truth about what it measures. It just doesn't measure the thing that matters this week.
The question for a library flaw isn't "are we patched?" It's "where do we have it?", and most organisations can't answer that quickly.
What good looks like
My view is simple. For any widely used library, a security team should be able to answer "which of our systems carry this, and at what version?" within an hour. Not perfectly, but well enough to start patching the right things first. Getting there takes four things.
1. An inventory of components, not just products
Ask for a software bill of materials, or SBOM, for software you build and software you buy. An SBOM lists the libraries inside an application and their versions, so a new CVE becomes a search instead of a survey. We explain how they work in our guide to what an SBOM is.
2. Supplier contracts that say who tells whom
Put it in writing: when a library inside your product has a critical flaw, the supplier tells you whether you're affected, and by when they'll ship a fix. Most suppliers will answer that question when asked. Very few volunteer it.
3. Rebuilds treated as patching
For containers and self-contained applications, the fix is a rebuild and redeploy. If your change process treats a rebuild as a development task rather than a security patch, it will always lag behind the advisory.
4. Runtime evidence as a backstop
Endpoint telemetry can show which processes actually load a library or run a runtime, whatever the inventory says. It won't find everything, but it finds the copies nobody listed. We gave worked examples for the Brotli flaw in our threat research post.
Who owns this?
Library flaws fall between teams. Infrastructure owns the servers, developers own the code, procurement owns the suppliers, and security owns the risk. When nobody owns the question "where is this library?", everyone assumes somebody else has answered it.
I'd give it to whoever owns vulnerability management, with a clear expectation that developers and suppliers feed it. That is the same argument we made about patching on platforms you don't run: outsourcing a component doesn't outsource the risk of the flaw inside it.
Three questions for Monday
- If a critical flaw landed in a common library today, how long would it take us to list every affected system?
- Which of our suppliers can give us an SBOM, and which have never been asked?
- Does our patch report count rebuilt containers and self-contained apps, or only installed updates?
If the honest answers are "days", "none" and "only updates", you are in the same position as most organisations we speak to. Our vulnerability and patch management service and our consultants can help close that gap. Talk to us about where to start.