What landed in CVE-land this week.

The lede is not another edge appliance. It is an authentication bypass in AI plumbing many teams deployed in the last six months without security review: BerriAI LiteLLM's Model Context Protocol (MCP) endpoint. CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on 2 September 2026; exploitation is confirmed, not theoretical. A second entry from the same KEV batch, CVE-2026-82329 in JFrog Artifactory, deserves a close read for the same reason: default configurations that hand administrative privileges to an unauthenticated attacker never age well.

CVE-2026-59822: LiteLLM MCP Streamable HTTP accepts any Bearer

Per the KEV entry, LiteLLM contains an improper authentication vulnerability in the MCP Streamable HTTP endpoint that allows an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.

MCP is the protocol many AI-heavy stacks now use to expose tools, data sources, and workflows to language models. LiteLLM, which sits in front of a fleet of LLM providers, added an MCP server so agents can call tools through the same proxy. In a correctly configured deployment, the MCP endpoint validates a Bearer token against the operator's identity provider or static key store. The advisory states that validation failed on the Streamable HTTP transport: any Bearer value, including one an attacker invents on the spot, was accepted as valid.

Two properties make this bug particularly nasty in production:

  1. MCP sessions expose tools. Depending on deployment configuration, an attacker can enumerate and invoke tools that reach internal systems, read files, or issue outbound HTTP requests on the server's behalf. Tool inventories vary by deployment, so exposure is site-specific; the auth bypass is the universal precondition.
  2. LiteLLM instances often sit inside the same trust boundary as the models and vector stores they serve. The blast radius includes prompts, retrieval sources, and any secret material the proxy handles for outbound calls.

To confirm exposure on your own perimeter, issue a benign initialize call with a garbage token and inspect the response. If the server returns a session id and negotiates a protocol version, it accepted an unauthenticated peer. Do this only against systems you are authorised to test.

POST /mcp HTTP/1.1
Host: litellm.example.com
Authorization: Bearer not-a-real-token-1234
Accept: application/json, text/event-stream
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {"name": "audit-probe", "version": "0.0.1"}
  }
}

A correctly configured server returns HTTP 401 with no Mcp-Session-Id header. A vulnerable server returns 200 with a session id and continues into a tools/list conversation.

Detection guidance for defenders:

Patch to the fixed release listed in the vendor's advisory. Until then, the least-bad workaround is to front the MCP endpoint with a reverse proxy that terminates auth itself (an OAuth2 proxy, a service mesh sidecar, or a WAF rule that requires a signed header) and to firewall the raw LiteLLM port to loopback.

CVE-2026-82329: JFrog Artifactory improper authentication under default configuration

The second KEV entry worth your attention is CVE-2026-82329. Per KEV, Artifactory contains an improper authentication vulnerability that under default configuration can allow an unauthenticated attacker with network access to obtain administrative privileges. Artifactory serves a large share of the software supply chain; administrative access to a build repository is administrative access to what ships to production.

Two things matter operationally. First, the "default configuration" qualifier means exposure is likely broad: instances deployed quickly or migrated between hosts rarely escape defaults. Second, an admin on Artifactory can create users, publish artefacts, poison a repository, alter proxy settings, and read secrets stored in the platform. A successful exploit is not a nuisance; it is a foothold on your release pipeline.

Immediate work for defenders:

A minimal log query to surface suspicious admin creation events (adjust field names to your telemetry) looks like this:

event.dataset:"artifactory.access"
AND action:"create_user"
AND target.user.role:"admin"
AND NOT source.ip:(10.0.0.0/8 OR 192.168.0.0/16)
| stats count by source.ip, target.user.name, @timestamp

Zoom out

Both CVEs describe the same class of failure: the front door believes whatever the caller says. LiteLLM believed any Bearer; Artifactory in default mode behaved as though the attacker was already authenticated. Add this failure class to your review checklist for anything you deploy this quarter. Every new HTTP surface that grants a session id needs an explicit test verifying that a garbage credential is rejected. Every default configuration needs a runbook entry listing exactly what a first-boot administrator must change before the system is network-exposed.

The rest of the week's KEV additions (a V8 type confusion in CVE-2026-85046, a Sangoma Switchvox SQL injection in CVE-2026-9586, two SonicWall SMA1000 flaws in CVE-2026-83548 and CVE-2026-83549, a Kestra OSS command injection in CVE-2026-49869, a Starlette request smuggling in CVE-2026-48710, and the PaperCut chain of CVE-2026-82078 with CVE-2026-81578) are all worth patching per vendor-stated urgency. If your inventory contains them, open the ticket today.

Verifiable security.