decrypted · 7 september 2026 · ransomware and cybercrime · vulnerabilities and patching · ai and llm security

The AI gateway bug that turned a failed login into a free pass

A widely used open-source gateway for running large language model applications, LiteLLM, spent months with an authentication check that failed the wrong way: when it could not verify who was calling, it let them in anyway. CISA added the flaw, CVE-2026-59822, to its Known Exploited Vulnerabilities catalogue on 2 September after researchers at Wiz observed attackers probing it in the wild. It is as clean a case study in Secure by Design as this newsletter has had this year.

A login failure that produced a blank pass

LiteLLM sits between an organisation's applications and the various AI models and tools they call, including through the Model Context Protocol (MCP), the increasingly common standard for letting an LLM invoke external tools. Its MCP endpoint supported OAuth2 "passthrough" authentication, checking a caller's key against an upstream server. According to the vulnerability's advisory, when that check failed for any reason, the code did not reject the request. It quietly substituted an empty, technically valid authentication object and let the call proceed.

Think of a nightclub whose ID scanner occasionally glitches, and whose fallback, rather than turning people away, is to wave them straight past the rope. An attacker who simply sent a fabricated Authorization header could trigger the glitch on demand, reach an organisation's configured AI tools with no credentials at all, and enumerate whatever those tools were connected to. Wiz says it has seen exploitation attempts against honeypots probing exactly this path. The flaw carries a CVSS score of 8.8. A fix shipped in version 1.84.0: anything earlier is exposed.

Fail shut, not open

The interesting part is not the bug, it is the shape of it. Nobody set out to build an authentication bypass. Someone wrote sensible-looking fallback code for a failure case, and the fallback was permissive rather than restrictive. That is a design decision, not a typo, and it is exactly the kind Secure by Design exists to catch: when a security check cannot complete, the system should default to denying access, not granting it silently.

For UK organisations racing to bolt AI tooling onto existing systems, often procured from vendors few boards have properly audited, the practical question is not just whether LiteLLM is patched, but what the wider AI stack does when its own checks fail. Worth asking any vendor selling an AI gateway, an agent framework or an MCP server:

That is a cheap question to ask now, and an expensive one to answer after an incident.

Also this week

Google patched its sixth actively exploited Chrome zero-day of the year on 4 September. CVE-2026-85046 is a type confusion flaw in the V8 engine that Google confirmed was already being used in attacks, and it deliberately withheld technical detail to slow attackers down while the fix rolled out. The update ships in Chrome 152.0.7977.82 for Windows and Linux (152.0.7977.82/.83 on macOS). If your organisation manages Chrome centrally, that update should already be forced out; if it does not, this is a reasonable week to start.

A UK packaging supplier, Complete Packaging Solutions of Leicester, appeared on the Qilin ransomware group's leak site on 4 September, with the attackers claiming to have stolen data and posting a screenshot as proof. Neither the claim nor the scale of any data taken has been independently verified, and the company has made no public statement. Leak-site postings are extortion leverage, not confirmed breaches, and are worth reading as exactly that until proven otherwise.

Sources

If you'd like to talk through what your AI stack does when authentication fails, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.

Prefer to listen? Decrypted on Apple Podcasts, or paste the podcast feed into any app.