The Brotli fix sat in public for eight months because nobody called it a security fix

A logging flaw with a 2.7 score turned out to be valuable enough for a nation-state to burn a zero-day. Meanwhile, eight vulnerabilities scored at the maximum 10.0 saw no exploitation at all. One Linux kernel race condition received four different severity scores, depending on the source. This week, the severity field did little to help anyone make sense of what mattered.

Let's start with the 2.7, because that number should make you rethink how you approach triage. CVE-2026–41709 is a case of insufficient logging in Broadcom VMware ESX: if an attacker already has administrative access, they can perform certain actions without leaving a trace. On October 28, CISA added it to the Known Exploited Vulnerabilities catalog and set a federal remediation deadline for November 11. CrowdStrike's rationale is telling: the China-linked group Warp Panda used this as a zero-day in early 2026 against the U.S. legal sector, aiming to erase audit trails.

A 2.7 falls below every emergency threshold in any policy I've seen. By the book, you would have been justified in ignoring it. Yet a state-sponsored group with real zero-day capability chose to use it-not for code execution, but to take away your ability to see what happened. The value here was silence, and there is no CVSS metric for that.

Now look at the other end of the scale. Hewlett Packard Enterprise patched 72 vulnerabilities in ArubaOS 8 and 10, eight of which scored a perfect 10.0. None are known to be exploited. If you let severity scores drive your priorities, this is where your attention would have gone all week.

Order these by exploitation status and reach, not by score. Always confirm each detail against the vendor advisory before acting.

• Brotli: CVE-2026–111497. Google scores it 9.2 on CVSS 4.0; Red Hat scores the same flaw 8.1 on CVSS 3.1; Microsoft scores it 8.1 for .NET and does not list remote code execution among the outcomes at all. In KEV since October 27; federal deadline November 10. An unchecked return value in the decoder. Fixed in 1.0.10, 1.1.1 and 1.2.1. Downstream: Node.js 22.23.4, 24.22.1, 26.12.1 (20.x and older are end of life); .NET 8.0.33, 9.0.22, 10.0.14, 11.0 RC3, out of band October 25; Bun 1.4.4; Envoy; Istio; Python Brotli 1.2.1. Still unfixed as of October 26: Ubuntu listed brotli and nodejs as needing evaluation on every release; SUSE's Node.js 22 update was in testing; RHEL had no patches for its nodejs:24 and nodejs:26 modules; and JFrog found the flaw reaches ClickHouse and Apache Arrow with no shipped fix. Khai Tran and Sylvie Mayer of OpenAI Codex Security reported it.
• PHP on Windows is the update you cannot spot by version number. PHP rebuilt its Windows binaries against Brotli 1.2.1 on October 26, but the PHP version string stayed the same. The only way to identify the fixed build is by the -1 in the filename and the SHA-256 on the downloads page. If your patch tracking relies on version strings, this fix will slip right past you.
• Cisco Secure Firewall ASA and FTD: CVE-2026–76418, CVSS 8.6. It's been exploited in the wild, and your tooling will rank it last. A logic error in the Remote Access SSL VPN service when secondary authentication is configured on a tunnel group lets an unauthenticated attacker force the device to reload-denial of service, not remote code execution. Cisco became aware of exploitation in October 2026 and has published nothing on the scale. ASA fixed in 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 and 9.24.10.1; FTD in 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 and 10.1.1. Cisco's note is the uncomfortable one: you don't need a successful VPN login to reach the affected path. The reporter is not credited in the report I read.
• HPE Networking ArubaOS 8 and 10: eight flaws scored at 10.0 out of 72 in advisory HPESBNW05162. No active exploitation so far, but patch it anyway. Three authentication bypasses (two of which give remote code execution in AOS-10 and AOS-8, one that exposes sensitive data via the PAPI protocol), two unauthenticated buffer overflows, two unauthenticated SQL injections, and one unauthenticated command injection. Upgrade to 10.8.1.2, 10.7.2.7, 10.4.1.14, 8.13.3.1, or 8.10.0.24 or later. The real reason to move is not the score, but the fact that some of these flaws live in device management protocols that may be exposed to wireless clients. Aruba gear often runs guest, hotel, and public Wi-Fi. This entry is from SANS NewsBites; I could not find a direct article.

Sources: The Hacker News on the Brotli versions and conflicting scores · The Hacker News on the October 27 KEV addition and the November 10 deadline · The Hacker News on the PHP Windows rebuild · The Hacker News on the Cisco ASA and FTD flaw. The entire ArubaOS entry comes from SANS NewsBites Vol. 28 Num. 80, cited as text because NewsBites uses click-tracking links; no outlet I could reach covered it

The change that closes CVE-2026–111497 went into Brotli's source on February 27. No release carried it until October 21. Aikido Security's account of why is the most useful sentence of the week: the root cause was fixed in February, "but it wasn't recognized as a security issue at the time and no release shipped with the fix until now."

That eight-month gap is the real lesson here, and it goes far beyond Brotli. A maintainer fixed a memory-safety bug, labeled it as a regular bug, and moved on. The entire pipeline that moves fixes to production triggers only for security bugs, not just any bug. No advisory, no CVE, no release note, no scanner signature, no ticket. Every system did exactly what it was supposed to do, and every one stayed silent, because they all depend on a single human judgment: is this a security issue? That call is made once, early, often by one person, and no one can guarantee they get it right. The classification itself became the vulnerability. Then, bundling turned one oversight into eight months of exposure across every ecosystem, since each project ships its own copy and update.

A word of caution, aimed more at panic than complacency. Three different practitioner groups spent the week urging the industry not to overreact, and they have a point. Sysdig's summary: so far, the impact is mostly large-scale crashes and code execution only in narrow setups. Red Hat reports no reliable public proof of concept. Imperva's Red Team needed several tries on a specific Node.js build. On the other hand, Wiz says 91 percent of cloud environments contain vulnerable resources. That is an exposure number, not an exploitation number, but it is being quoted as if it were. Both things are true: this is widespread and barely exploited. The right response is a thorough, unhurried, complete remediation. That is not the same as an emergency, and it is the kind of work most organizations struggle to do well.

Sources: The Hacker News for the February 27 source-fix date and the Sysdig, Red Hat, and Imperva findings · CyberScoop for Beek by name and title, the Wiz percentages, and the case that the alarm is overstated. The Aikido quotation is from SANS NewsBites Vol. 28 Num. 80, cited as text

Look back at each story this week and ask: did the score actually tell you what to do? The 2.7 was worth a zero-day. Nobody is exploiting the eight 10.0s, while a Cisco VPN flaw scored 8.6 and is being exploited right now, though it only reboots a firewall. One Linux kernel race got four different scores, even from the same vendor, and the disagreement is about how easy it is to exploit, the very thing the score is supposed to clarify. Brotli had no score for eight months because a maintainer filed a memory-safety fix as a bug. Tailscale's eleven findings have no CVE and no score at all.

Five different failures, one shared cause: we have outsourced the judgment about what matters to a field, and that field is built by a process with no authority, no consistency, and no obligation to be right. CVSS was meant to describe technical characteristics, but we use it to decide where people spend their time. Those are not the same job. This week shows what happens when the gap between them gets wide enough to walk through.

Now for the pushback, starting with my own framing. "Stop trusting CVSS" is the easy takeaway, but it is not useful, because most people reading this do not get to choose. The score comes embedded in your scanner, your compliance requirements, your contracts, your board reports. If you announce the numbers are unreliable, you will rightly be asked to show the new threshold in writing. And "reachability" is not a number you can put in a service level agreement. If all this lands as simple skepticism about scoring, nothing changes, and you lose the one shared language you have with your auditors.

So here is the narrower version I would stand behind: keep CVSS for what it does well, triaging the long tail you will never look at one by one, and add just two things: an override lane and an exception list. The override lane covers your tier-zero assets: hypervisors, identity, EDR, log pipelines, network control planes. Treat any flaw that touches logging, auditing, or telemetry integrity as high severity, regardless of the published score, and put exploitation status before CVSS on every row. The exception list is for the handful of internet-facing software where you know exploitation will move faster than your process, so you pre-authorize the fast path. Both are additions, not replacements, which is why they work with governance. The organizations that handled this week well were not the ones with better judgment about scores; they were the ones that already knew which twenty hosts actually matter.

When a fix exists for a component we ship, but nobody has labeled it a security fix, how would we ever know? And who in this organization actually gets to decide that a bug is a vulnerability?

Ask yourself this about one dependency you ship. If your answer is "our scanner would tell us," go check what actually triggers your scanner. Is that a guess, or do you know? I read every reply.

Originally published at https://www.linkedin.com.