CVE-2026-71277 isn't an authentication bypass—it's an authentication layer that was never implemented. The AuthToken guard performs a single check: does an Authorization header exist? If yes, access is granted. There is no session lookup, no signature verification, no expiry checking. The guard carries the name of a security control but performs none of its functions. This is security theater: protection on paper, none in practice.
The CVSS 9.1 is technically accurate but obscures the nature of the failure. This wasn't a clever circumvention of a properly designed mechanism—it was a mechanism that existed only by naming convention. When reviewers encountered a guard named AuthToken, cognitive closure did the work the code should have done: the guard exists, it's named correctly, therefore authentication exists. The abstraction that makes guard patterns valuable (you shouldn't have to reason about authentication at every endpoint) became the mechanism of its own failure. The framework suppressed the exact scrutiny that would catch missing implementation.
The downstream exposure is the more important question. An IoT platform with this vulnerability almost certainly feeds device provisioning, telemetry ingestion, or firmware push mechanisms. Those downstream systems didn't just receive requests that passed the guard—they trusted those requests with privileged operations. The false negative of "this header check means authentication happened" propagated laterally into every system consuming this API. You need to map not just what can hit this endpoint, but what this endpoint enables in systems that trust it.
The EPSS of 0.00241 deserves skepticism. Trivially exploitable critical vulnerabilities scoring low typically reflects a structural blind spot: EPSS models exploitation difficulty, and "any request with any header works" reads as "too easy to be interesting" rather than "high priority." For defenders, that's backwards—the absence of tooling requirements is an amplifier, not a limiter. Any compromised container, internal service account, or supply chain component with network access can exploit this. The population of entities that can trivially exploit this is orders of magnitude larger than those that could exploit a sophisticated auth bypass. Low EPSS with massive blast radius is the combination that should keep you up at night.
The commit history is your critical investigation. Two failure modes are possible: the guard was scaffolded and never finished (abandoned code), or token validation was removed at some point (degraded code). These require different response postures. If validation was gutted rather than never delivered, you need to understand why a security-relevant change went unreviewed. Any fix you implement now will be a reconstruction of what authentication should look like, not a recovery of what was lost—the original intent may be unrecoverable without source archaeology.
Check your downstream trust relationships now. Assume any system that consumed this API with "protected endpoint" in its mental model was operating on a false premise. Patch the guard, but also audit what operations it was protecting.