How this bug class keeps getting shipped

Authentication that fails open is the oldest entry in the CWE catalog, and it keeps reaching production. Two additions to CISA's Known Exploited Vulnerabilities catalog in early September 2026 share the same failure mode: a service accepts a credential without verifying it, and an unauthenticated caller inherits the privileges that credential is supposed to gate. The bug class is worth studying not because it is exotic but because it is embarrassingly consistent. The same shape has been shipped in web apps, in appliances, in package repositories, and now in the plumbing that connects large language models to tools and data.

The lead example is CVE-2026-59822 in BerriAI LiteLLM, added to KEV on 2 September 2026. CISA's entry states that LiteLLM "contains an improper authentication vulnerability in the MCP Streamable HTTP endpoint that could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token." The mechanism is plain. LiteLLM exposes a Model Context Protocol server over HTTP so agents can call tools. MCP's transport carries an Authorization: Bearer <token> header. The server takes the presented token, opens a session, and treats subsequent traffic as authenticated. The verification step, the part that maps the token string to a known principal, never runs. Present anything, get a session; the tokens are self-asserting.

That distinction between "presented" and "verified" is where this bug class lives. A correctly implemented Bearer flow does at least three things before minting a session: parse the token, validate the signature or query a trusted store for the opaque value, and resolve the caller to a principal with a defined scope. Skipping any one of those steps produces a surface that looks like authentication but is not. The tell in an HTTP trace: the header appears in every reasonable request, yet no request is ever rejected for a bad token, only a missing one. A trivial probe makes it obvious:

POST /mcp/v1/session HTTP/1.1
Host: mcp.example.com
Authorization: Bearer notatoken
Content-Type: application/json

{"clientInfo":{"name":"probe","version":"0.1"}}

HTTP/1.1 200 OK
Content-Type: application/json

{"sessionId":"9c7f...","serverInfo":{"name":"litellm-mcp"}}

If any string in the Bearer position yields a session and that session can list or invoke tools, the endpoint is failing open. The same probe with the header omitted should return 401; the header present with garbage should also return 401. If those two responses differ, the service is doing presence-checking rather than validation.

The blast radius depends on what the MCP server can reach. LiteLLM routinely brokers calls to hosted model APIs, holds provider keys in its configuration, and can connect to tool servers that touch internal systems. An attacker who establishes a session on the MCP endpoint inherits whatever that server can do: enumerate models and providers, invoke tools meant only for authorised agents, and in deployments where LiteLLM holds long-lived API keys, abuse those keys. This is not a theoretical concern; CISA added CVE-2026-59822 to KEV because it is being exploited.

The second entry in this KEV batch shows the same failure class from a different angle. CVE-2026-82329 in JFrog Artifactory is described by CISA as an "improper authentication vulnerability that under default configuration can allow an unauthenticated attacker with network access to obtain administrative privileges." The key phrase is "under default configuration." That is not a subtle hardening gap; it is an authentication path that mints an administrative session for a caller who proved nothing. Artifactory sits behind organisational build pipelines, holds signing material and package caches, and is often reachable from more of the internal estate than its operators realise. An unauthenticated admin on that surface is a supply-chain incident in waiting.

Read together, LiteLLM and Artifactory land in the same slot on the CWE map: presented credentials trusted without a verification step, across code paths representing supported, default deployments. Neither is a memory-safety bug, neither requires a chained RCE primitive, and neither requires an authenticated foothold to start. That is why both earned KEV listings within days of publication.

Two defensive habits reduce how often this shape ships. The first: write authentication tests that assert the negative case, not only the positive one. A CI check that only proves "a valid token works" cannot catch a server that accepts any token. The suite must include a malformed Bearer, an expired token, and a signature from a different issuer; each must return 401 with the exact body the client expects. The second habit is to keep identity-resolving code in one place. When every new transport (WebSocket, gRPC, MCP over HTTP) re-implements its own header parsing and session minting, the odds that one forgets to call the verifier climb with each addition. A single middleware that fails closed and is impossible to bypass by construction is far cheaper to review than five bespoke handlers.

The practical checklist for defenders is short. Inventory every service that speaks a Bearer-token protocol on any network segment an unauthenticated caller can reach, including MCP endpoints, package registries, and artifact stores. For each, run the two-request probe: header absent, then header present with an obviously invalid value. Anything that returns a session, a listing, or an admin surface on the second request belongs to the same bug class as CVE-2026-59822, whether or not it has its own CVE yet. Patch to the vendor's current release, restrict network access to these control planes to the identities that need them, and rotate any long-lived credentials the affected service holds. A session that should never have been granted may have already read those credentials.

Verifiable security.