On 27 October 2026, CISA added two actively exploited vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, with a federal remediation deadline of 10 November:
CVE-2026-111497, a flaw in Google's Brotli compression library, rated CVSS 9.2, known as Node2Shell and more recently Broccoli2Shell
CVE-2026-48356, an unrestricted file upload flaw in Adobe Commerce and Magento, rated critical, known as PolyShell
One correction before anything else, because it changes how you should treat both. Neither of these is a zero-day. A zero-day is a flaw being exploited before a fix exists. Adobe shipped its fix in July 2026, more than three months before this listing. Brotli fixes shipped about six days before CISA acted. These are known, patched vulnerabilities being exploited against organisations that have not applied the updates.
That is not a smaller problem. It is a different one, and it has a different solution.
What happened
The Brotli flaw
Brotli is a compression format and library developed by Google, used to make web traffic smaller. It is everywhere: browsers, web servers, CDNs, programming language runtimes and countless applications that never mention it by name.
CISA's catalog entry describes what an attacker gets: the ability to "corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service", or potentially execute arbitrary code, using a crafted Brotli-compressed stream.
The technical class is an unchecked return value leading to an out-of-bounds write in the decoder. The attacker is remote and unauthenticated. The input is simply compressed data that the victim's software decompresses.
Affected versions: Brotli 1.0.3 through 1.2.0. Fixed versions: 1.0.10, 1.1.1 and 1.2.1.
The flaw was initially called Node2Shell, because it surfaced through Node.js. Since the start of that week it has been clear that it affects anything using Brotli libraries to decode the format, not just Node.js, which is where the second name came from.
Downstream projects and vendors have shipped their own updates, including Node.js, PHP, Bun and Microsoft .NET, with Microsoft pushing an emergency .NET security update. Red Hat published advisory RHSB-2026-015.
Wiz research reported that 91% of cloud environments are affected, which gives a sense of how broadly the library is embedded.
The Adobe Commerce flaw
CVE-2026-48356 is an unrestricted upload of a file with a dangerous type, in Adobe Commerce and Magento Open Source. An unauthenticated attacker can upload a file and achieve code execution in the context of the current user account, and potentially expand access from there.
Affected releases include Adobe Commerce 2.4.9, 2.4.8-p5 and earlier supported releases, and Magento Open Source 2.4.9 and earlier. Adobe fixed it in July 2026 under bulletin APSB26-73.
Severity scores reported for this flaw differ between sources, with 9.3 and 9.6 both appearing. Either way it is critical.
Security firm Sansec has analysed a campaign using this class of attack, reporting that the group behind it has compromised at least 953 shops since July 2025, mostly running Magento, and used the PolyShell flaw to upload web shells.
What CISA did not say
For both entries, CISA gave no details about the attacks: not who is exploiting them, not which products are being hit, not when the activity started, and not how widespread it is. Ransomware use is listed as unknown for both.
That silence is normal for KEV entries and it is also a practical problem, because it leaves defenders without indicators to hunt for.
Why the Brotli flaw is harder than it looks
This is the part that deserves most of your attention, and it is not about severity.
You probably cannot patch Brotli directly. It is a library bundled inside other things. Your exposure sits in your Node.js runtime, your PHP installation, your .NET applications, your container base images, your appliances, and in commercial software whose vendor has not told you whether it uses Brotli at all.
The practical consequence: the fix usually belongs to somebody else. You are waiting on a runtime update, a base image rebuild, or a vendor advisory. Your job is to find out which, for each affected system, and that discovery work is the bottleneck rather than the patching itself.
Software inventories will not help as much as you would like. Brotli will not appear in most asset lists because nobody installed it deliberately. It arrived as a dependency of a dependency.
There is a usable stopgap. Until updates land, organisations can block incoming Brotli-compressed requests at the proxy or firewall, or switch off Brotli decoding. This costs performance and may break some clients, but it removes the attack path. For internet-facing systems where patching will take days, it is worth considering.
Why it matters
"Exploited" and "zero-day" are not the same thing, and the difference determines your response. A zero-day means waiting for a vendor. An exploited known flaw means the fix already exists and the gap is yours to close. Adobe's patch has been available since July. The organisations being compromised through it had more than three months.
The KEV listing is the signal that changes priority. A critical CVSS score alone is not evidence anyone is attacking you. A KEV entry is. For US federal agencies, Binding Operational Directive 22-01 makes the 10 November deadline binding. For everyone else, it should function as an escalation trigger, because it means the theoretical has become actual.
Magento stores are a standing target. Sansec's figure of at least 953 compromised shops shows this is an industrialised campaign, not opportunistic probing. E-commerce platforms hold payment flows and customer data, and web shells planted months ago may still be live on stores that have since been patched.
Patching Magento is not the end of the job. If your store was unpatched between July and now, you may already have a web shell or injected CMS blocks. Updating closes the door and does nothing about anyone already inside.
Dependency depth is the real lesson. A compression library most teams have never consciously chosen is now a remote code execution risk in 91% of cloud environments. That is what modern software supply chains look like.
Who is affected
Any system running Brotli 1.0.3 through 1.2.0, directly or bundled.
Node.js, PHP, Bun and .NET estates, all of which have shipped updates.
Cloud environments broadly, with Wiz putting the affected share at 91%.
Container images and embedded runtimes, where the library is least visible.
Adobe Commerce and Magento Open Source stores on 2.4.9, 2.4.8-p5 or earlier that missed the July 2026 updates.
US federal civilian agencies, which face a binding 10 November deadline for both.
Anyone running commercial appliances or vendor software, who may not yet know whether Brotli is inside.
What organisations should do
For Brotli, in order
Find out where Brotli is. Check your runtimes first: Node.js, PHP, Bun, .NET. Then container base images, then appliances and commercial software. This discovery step is the work.
Apply the updates your vendors have shipped, including the emergency .NET update and Red Hat's RHSB-2026-015 guidance.
If you compile or bundle Brotli, move to 1.0.10, 1.1.1 or 1.2.1, depending on which branch you are on.
Where patching will take days, block Brotli-compressed requests at the proxy or firewall, or disable Brotli decoding. Treat this as temporary and accept the performance cost.
Ask vendors directly whether their products bundle Brotli, and record the answers. Most will not have told you proactively.
Rebuild container images rather than patching running containers, so the fix survives the next deployment.
For Adobe Commerce and Magento
Confirm you are on a release that includes the July 2026 fixes (APSB26-73). If you are not, that is now the priority above everything else on your list.
After patching, hunt for what may already be there. Look for web shells, unexpected files in upload directories, injected CMS blocks, unfamiliar admin accounts and modified templates.
Review access and payment flows, since this class of compromise targets both.
Check your hosting provider's patching responsibility. For managed Magento, the update may be theirs, and that needs confirming rather than assuming.
Process
Wire KEV into your prioritisation as an automatic escalation, not as a reference list someone checks occasionally. Its entire purpose is to tell you what is actually being attacked.
Treat "the fix belongs to someone else" as a tracked state, not a dead end. Record which vendor you are waiting on, chase it, and apply compensating controls in the meantime.
Note that CISA published no indicators, so detection here depends on your own hunting rather than on a published list.
Final thoughts
Two critical flaws, both under active attack, neither of them new. Adobe fixed one in July. The Brotli project and its downstream vendors fixed the other a week before CISA listed it. The exploitation is happening in the gap between a fix existing and a fix being installed, which is where most real-world compromise lives.
The lesson: for embedded libraries, the hard part is not patching, it is knowing where the thing is. Brotli is in 91% of cloud environments according to Wiz, and almost nobody chose to put it there. It arrived inside a runtime, inside an image, inside a vendor's product. You cannot patch what you cannot locate, and the discovery work that follows a disclosure like this is slower and less glamorous than the patch itself.
The second lesson is for anyone running a Magento store. The July patch stops new intrusions. It does nothing about a web shell that has been sitting on your server since August. Patching and incident response are two separate pieces of work, and skipping the second because you have done the first is how organisations end up compromised by a vulnerability they believe they fixed.
Two things worth doing today: list every runtime and container image in your estate that includes Brotli, and confirm the exact Adobe Commerce release your store is on.
