One Letter Was the Password: Attackers Are Already Inside Enterprise AI Gateways
Honeypot data caught live exploitation of the AI stack — and the federal patch deadline landed today
September 16, 2026 | By The CyberSurv Team | CyberSurv
The letter “x.” That’s all it took. Send any Bearer token — a single character worked fine — to a vulnerable LiteLLM gateway and you had an authenticated session with its connected MCP servers. No brute force, no phishing, no zero-day wizardry. Just one letter where a password should be.
That flaw, CVE-2026-59822, landed in CISA’s Known Exploited Vulnerabilities catalog on September 2. Federal agencies had until today, September 16, to fix it. If your organization runs an AI gateway and nobody owns that patch, you’re now behind the government’s own clock.
We’ve spent months writing about attackers who log in rather than break in through VPNs and firewalls. The same playbook has now arrived at the newest door on your network: the infrastructure running your AI.
Four Federal Red Flags in Five Months
LiteLLM is one of the most popular open-source AI gateways — the traffic cop that sits between your applications and model providers, holding the API keys for all of them. It’s exactly the kind of quiet middleware that spreads through an enterprise faster than the asset inventory can track it.
Here’s the part that should stop you mid-coffee. Since May, this one product has accumulated four entries in CISA’s exploited-in-the-wild catalog: a SQL injection flaw in May, a command injection bug in June, and on September 2, the one-character authentication bypass plus a related HTTP smuggling flaw in the underlying Starlette framework. Four KEV listings in five months is a pace that mature, decades-old products rarely manage. The AI stack is achieving it in its infancy.
Exposure makes it worse. Wiz Research found 3,074 LiteLLM gateways on the open internet in February — and nearly one in ten accepted “sk-1234”, the example admin key printed in the product’s own setup guide. Most of those had no key configured at all. The rest never changed the default.
What 90 Days of Honeypot Data Revealed
Exposure alone doesn’t prove anyone’s knocking. So Wiz built decoys and watched. Their 90-day honeypot study, published August 27, removed all doubt: attackers are running purpose-built playbooks against AI infrastructure, not just spraying generic exploits.
The observed chain reads like a pentest report. Attackers used the authentication bypass for reconnaissance, enumerating which models a gateway could reach. Then they abused the command injection flaw in an MCP test endpoint to spawn a Python downloader, pull a cryptominer from attacker infrastructure, and stage it in a hidden directory that survived cleanup. Microsoft, tracking the same activity, watched intruders harvest container environment variables — master keys, provider credentials, database connection strings — then walk straight into the PostgreSQL database behind the proxy.
Cryptomining is the smoke, not the fire. The same access that installs a miner can read every credential the gateway holds. Microsoft’s advice was blunt: treat AI gateways as Tier-0 secret stores — the same class of crown jewel as your domain controllers. We made the same argument when ServiceNow’s AI platform picked up three perfect-10 flaws. The pattern is holding.
Prompt Injection Has Left the Lab
The honeypots caught something else, and it deserves more attention than it’s getting: blind prompt injection attacks against real-world agent frameworks, including LangChain, Flowise, and Node-RED. Attackers submitted instruction-override payloads designed to make an AI agent invoke its shell tools, with DNS callbacks to confirm which victims obeyed. Some payloads arrived Base64-encoded via Pastebin.
For two years, prompt injection lived mostly in conference talks and proof-of-concept papers. Now it’s a commodity technique observed against live infrastructure. And the post-exploitation tradecraft is adapting to AI environments specifically — attackers queried Python module state to lift API keys straight from gateway memory, and disguised their tooling inside legitimate AI directories where an admin would never look twice.
Anthropic’s September threat report frames the shift well: malicious use of AI has moved from interactive chat abuse toward autonomous, agentic execution. The attackers are building agents. They’re also hunting yours.
Why Critical Infrastructure Operators Should Care
If you run a port terminal, a vessel fleet, or an industrial plant, this may feel like an IT problem. It isn’t. AI gateways and MCP servers exist to connect models to real systems — ticketing, databases, historians, document stores. Every connection is a bridge, and bridges carry traffic in both directions.
Maritime and OT operators are adopting AI copilots for scheduling, maintenance planning, and compliance paperwork at remarkable speed. Each deployment quietly adds an internet-reachable service that holds credentials, executes code, and rarely appears in the security team’s asset inventory. Sound familiar? It’s the exact lifecycle that made VPN concentrators and firewalls the most-attacked devices in the maritime sector. The AI gateway is the next edge device — except this one can act on your behalf.
One more wrinkle: LiteLLM’s maintainers consider administrators trusted by design, so some risky behaviors — like pass-through endpoints reaching cloud instance metadata — won’t be patched at all. When the vendor’s threat model and your threat model disagree, the difference lands on you.
How We’d Approach It
You don’t need to rip out your AI stack. You need to govern it like the privileged infrastructure it is.
- Inventory first. Find every AI gateway, agent framework, and MCP server in your environment — including the ones a developer stood up last quarter. You can’t patch what you haven’t found.
- Kill the defaults. Rotate any master key that resembles documentation. Require authentication everywhere. “sk-1234” is not a credential; it’s an invitation.
- Patch to current, today. LiteLLM 1.84.0 or later closes the exploited flaws. If you can’t upgrade immediately, block MCP and test endpoints at your reverse proxy.
- Contain the blast radius. Restrict outbound network access from AI hosts, apply least-privilege credentials, and monitor process ancestry — a gateway spawning shell commands is a five-alarm signal.
- Test it like an attacker. Our penetration testing engagements now routinely include AI gateways and agent tooling, because that’s where real adversaries are spending their time.
For organizations without a deep security bench, this is precisely the gap our RiskGuard 365℠ program covers — continuous visibility into new attack surface, KEV-driven patch prioritization, and monitoring that flags an AI host behaving badly before a miner (or worse) settles in. And if the strategy question — who owns AI security? — is the sticking point, our Security Leadership Program puts executive-level ownership behind it.
Final Thoughts
Every wave of enterprise technology follows the same arc: rapid adoption, quiet accumulation of privilege, then a rude introduction to the threat landscape. AI infrastructure just had its introduction. Ninety days of honeypot data show attackers who understand MCP protocols, harvest keys from memory, and weaponize prompt injection against production agents.
The federal deadline was today. The attackers started months ago. The organizations that come through this well won’t be the ones that adopted AI slowest — they’ll be the ones that treated it as critical infrastructure from day one.
Let’s Explore What’s Possible
Whether you’re deploying your first AI copilot or securing a fleet of agents across IT and OT, we’ll help you find the exposure before someone else does. From maritime cybersecurity assessments to continuous monitoring with RiskGuard 365℠, CyberSurv brings enterprise-grade security to the systems you can’t afford to lose.
