Severity Daily

IT and AI security incidents, checked against the primary source

Tag: LiteLLM

  • Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four items published today carry a federal remediation deadline of Saturday, September 5. That is two days out, and it is the day’s lead. It outranks the four fresh 9.8s that landed alongside it, because a 9.8 with no confirmed exploitation and no clock attached is a patch you schedule, and a Saturday deadline is a patch somebody has to be at a keyboard for. Two of those 9.8s do not have a release number to install anyway.

    The thread is real, and it is CISA’s. Six of today’s ten stories trace back to one batch of Known Exploited Vulnerabilities additions made on September 2 — four due September 5, two due September 16. Running underneath it is the same problem in three of the four Saturday items: the authoritative record does not cleanly say what to install.

    Deal with SonicWall’s SMA1000 pair first. It is an internet-facing access appliance, it is the third zero-day pair on that product, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one — two days before the deadline. Then JFrog Artifactory, where CISA’s listing is the first government confirmation that the unauthenticated administrative bypass is being exploited, and where the medium-severity Artifactory CVE listed six days earlier is now due five days later than the critical one. Then Sangoma’s Switchvox, where the release notes mark the fix for both cloud and on-premises but the only CPE on the record covers on-premises, so an agency running the cloud edition cannot tell from the record whether it is in scope. Then Kestra, the one of the four whose difficulty is a label rather than a version: CISA files it as OS command injection, and what an attacker actually reaches is a filter asking whether a request path ends with the word configs.

    The two September 16 items are lower on the clock and higher on reach. Starlette’s BadHost is a 6.5 by three independent scorers, which is the number most likely to send a KEV entry to the bottom of a patch queue — and Starlette is what FastAPI is built on, so the inventory question is not “do we run Starlette” but “what did we build on FastAPI.” LiteLLM is the narrower one, and the sharper bug: the MCP endpoint answered a failed key check by substituting an empty authorization object and letting the request through.

    After the clocked items, the 9.8s. Cisco’s Nexus 9000 Silicon One root RCE names ten switch SKUs and points its Fixed Software section at an interactive tool instead of a release number; the record has no CPE data at all. Cisco’s IOS XR hardening release, published the same afternoon, packages an internal audit into seven CVEs across every release, two of them 9.8, with one CVE ID standing for thirteen distinct weakness types. That is Cisco twice in one day, both times with a remediation story that is harder to read than the vulnerability. Delinea’s Secret Server takes a 9.8 at the FIDO2 registration step in a privileged access manager, and NVD deferred the record the following day, leaving it with no machine-matchable version data. And thirteen Craft CMS CVEs arrived from two CNAs, neither of them Craft, onto advisories that say “No known CVE” — with one advisory drawing two IDs and one record carrying a description for a different bug.

    What is still open. SonicWall has not named a fixed build for either SMA1000 CVE with the deadline on Saturday. JFrog has published no in-the-wild statement of its own; the government confirmed exploitation before the vendor did. Sangoma has not resolved the cloud-versus-on-premises scope on the record itself. Cisco’s first IOS XR fix that is not a software maintenance update has not shipped, and it revised the fixed-release list within six hours of publishing it. The Delinea record is deferred, so scanners matching on CPE will not flag an affected install.

  • LiteLLM’s MCP endpoint answered a failed key check with an empty auth object, and CISA put it on a September 16 clock

    LiteLLM’s MCP endpoint answered a failed key check with an empty auth object, and CISA put it on a September 16 clock

    When LiteLLM’s key validation failed on its MCP endpoint, the code substituted an empty authorization object and let the request through — CISA added it to the KEV catalog on September 2 with a September 16 deadline.

    What happened

    CISA added CVE-2026-59822 in LiteLLM to the Known Exploited Vulnerabilities catalog on September 2, 2026. NVD’s record carries the fields verbatim: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-16, and the catalog name “BerriAI LiteLLM Improper Authentication Vulnerability.”

    LiteLLM is an AI gateway — a proxy that presents many model providers behind one OpenAI-compatible API, handles keys and budgets, and, increasingly, brokers Model Context Protocol tool calls on behalf of the applications in front of it. The flaw is in that last part. NVD’s description: “Prior to 1.84.0, LiteLLM’s MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key.”

    The project’s advisory, GHSA-7488-6r32-c95q, published June 30, 2026 and titled “MCP Authentication Bypass via OAuth2 Passthrough Fallback,” describes what that reaches: an attacker could “list and call configured MCP tools and access connected services exposed through MCP” with no valid credential. Affected versions are everything below 1.84.0. The fix is 1.84.0. The advisory credits a reporter it names as yaaras, and gives a workaround for anyone who cannot upgrade: disable the MCP routes, or block /mcp/ and related MCP resources at the reverse proxy or API gateway.

    Two scores sit on the record and neither is a dispute. GitHub’s advisory database supplies CVSS 4.0 at 8.8 High; [email protected] supplies CVSS 3.1 at 8.2 High on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. The CWE assignments are CWE-287 for improper authentication and CWE-306 for missing authentication for a critical function.

    The exploitation evidence traces to one place. NVD’s reference list includes Wiz’s writeup of an AI infrastructure honeypot, and that writeup states that Wiz “observed exploitation of this vulnerability in our honeypots, with requests using single-character tokens to probe model enumeration endpoints.” The captured request is a single line: GET /v1/models HTTP/1.1 with Authorization: Bearer x.

    Why it matters

    Look closely at what the code did, because the shape of it is the story. This is not a missing authentication check. LiteLLM validated the key. The validation failed. And on that failure path, the OAuth2 passthrough fallback substituted an empty UserAPIKeyAuth() object — a successfully-constructed authorization result carrying no identity — and execution continued as though a caller had been identified.

    This publication covered the identical shape yesterday in F5’s njs, where js_access control failed open when the JavaScript raised an exception. The lesson repeats because the mistake is structural: the error path of an authorization control is itself an authorization decision, and it is the path nobody writes a test for. A missing check gets caught in review, because the absence is visible. A check whose failure branch returns an empty success object looks, in a diff, like careful defensive coding.

    The word “fallback” is doing the damage here. A fallback is what you write when the primary path might legitimately not apply — and OAuth2 passthrough is exactly such a case, since the point of it is that some upstream MCP servers do their own authorization. But “this request might be authorized by someone else” and “this request failed my authorization” are different conditions, and the code treated them as one.

    Then there is what sits behind the endpoint. The instinct on reading “AI gateway breach” is to think about model access — someone burning your inference budget, or reading prompts. The MCP surface is a different thing. MCP tools are the gateway’s connections to real systems: databases, ticketing, source control, internal HTTP services, filesystems. Listing them tells an attacker what an organization has wired into its agents. Calling them is action taken against those systems, with whatever credentials the gateway holds for them, and the calls arrive from the gateway’s own network position and appear in downstream logs as the gateway. There is no user identity in any of it, because the authorization object was empty.

    That is also why the CVSS 3.1 vector deserves a second look. It reads C:H/I:L/A:N — high confidentiality impact, low integrity impact, no availability impact. For an endpoint whose defining capability is calling tools that change state in other systems, low integrity is a defensible reading of the gateway itself and an understatement of the deployment. It is the same component-versus-deployment gap that showed up on the Starlette entry CISA added the same day.

    The exploitation evidence needs to be stated at its real size, which is small. It is one vendor’s honeypot data, gathered over 90 days across AI and ML services. Wiz published no count of attempts, no dates within that window, no geography, and no figure for how many honeypots were hit. What it published is a pattern, and the pattern is informative even without a number: Authorization: Bearer x is a one-character token. Nobody sends that hoping it is the right key. It is a probe that asks whether any token gets through — the precise test for a fail-open bug, run indiscriminately. That is scanning behavior, and scanning behavior is what CISA’s exploitation determinations are usually built on.

    One more thing for anyone running LiteLLM. It is on the list of downstream projects affected by BadHost, the Starlette Host header flaw that CISA added to the catalog the same day, on the same September 16 deadline. A LiteLLM operator therefore has two KEV entries due at once: one in the application and one in the web framework underneath it, both of them authentication bypasses, both reached over the same listening port.

    The fix shipped June 30, 2026. The catalog listing came September 2 — 64 days. As with Kestra earlier in the same batch, the vendor did its part on time and the exposure being put on a clock is patch lag on self-hosted infrastructure that most organizations stood up quickly and have not yet folded into a normal patch cycle.

    What to do

    Get the running LiteLLM version. Anything below 1.84.0 is affected; 1.84.0 or later is fixed. Container deployments pinned to latest at build time are not evidence of anything — check the image that is actually running.

    If an upgrade cannot happen inside the window, apply the project’s own workaround: disable MCP routes, or block /mcp/ and the related MCP resources at the reverse proxy. That closes the path without touching the gateway’s model-serving function.

    Assume the endpoint was probed. Search access logs for requests to /mcp/ and to /v1/models carrying implausible bearer tokens — single characters, obvious test strings, repeated identical values from many addresses. Then check the tool side: MCP tool invocations that do not correlate to a known LiteLLM key or user, and activity in the connected systems arriving from the gateway’s address outside normal application hours. Because the bypass produced an empty authorization object rather than a borrowed one, an unauthenticated call will have no key attribution at all, which makes it findable if your logging records the key.

    If you find calls you cannot account for, rotate the credentials the MCP servers hold for downstream systems, not just the LiteLLM keys. The LiteLLM key was never the thing that was used.

    Federal agencies have until September 16, 2026. The required action carries CISA’s forensic triage clause and the discontinue-use provision where mitigations are unavailable, so the asset assessment is part of the obligation rather than a follow-up.

    Sourcing note

    KEV dates, the catalog vulnerability name, the required action text, the description, both CVSS entries with their assigners, and the CWE assignments come from NVD’s API record for CVE-2026-59822, which republishes CISA’s fields verbatim. The advisory title, affected and fixed versions, the description of what MCP access reaches, the workaround, and the reporter credit come from LiteLLM’s own GitHub Security Advisory GHSA-7488-6r32-c95q, published June 30, 2026.

    The exploitation observation is single-vendor: Wiz’s AI infrastructure honeypot writeup, referenced from the CVE record. It reports a 90-day observation window and gives the probe pattern, but publishes no count of attempts, no dates within the window, no geographic breakdown, and no number of honeypots involved. We asked for those figures and they are not in the source. Nothing here should be read as a measure of how widely the flaw has been exploited.

    CISA’s alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD — NIST republishing CISA, a government primary source, but one that lags the catalog and is not the catalog itself. Unresolved: whether the exploitation CISA relied on is the same activity Wiz observed or separate reporting, and whether any successful MCP tool calls, as opposed to enumeration probes, have been documented against a live deployment.