The Gateway With No Lock

DerekOkay, so get this. Somebody typed a bearer token they made up on the spot, and an AI gateway said, "Welcome in. Here are all the tools." Made up as in not issued, not stolen, just vibes? Pure vibes. And CISA looked at that and put it on the must patch list. Dude. I'm Derek, and this is Autonomous Autopsy. I'll be walking the kill chain. And I'm Max. My job is pressure testing the defense side, asking whether anyone's controls would have caught it, which, spoiler, is my favorite kind of bad news. CISA's official alert is dated September 2nd, 2026, and it adds seven vulnerabilities to the KEV catalog. Seven, and one of them is CVE-2026-59822. Listed as a BerriAI LiteLLM improper authentication vulnerability, which is a very polite way for what we're about to describe. AI Weekly flagged it too, noting that one of the seven sits inside an AI proxy a lot of teams run. Wait, improper authentication. So the gateway did check something? It checked the key, the key failed, and it let the caller in anyway. A bouncer who looks at your fake ID, shrugs, and holds the door. Exactly. And nobody had to be clever. No exploit chain, no poisoned prompt, just a request that showed up carrying a string. Which makes it a strange thing to find on a list of bugs that are known to be exploited. Wait for it, because the fallback is even better. We'll get the kill chain, then ask whether this is really a first like the headlines claim, and finish with a Monday checklist. Fine, but start with the bug itself. First, what actually happened inside that gateway? Okay, so the mechanism. Three steps, and every one of them is boring, which is the whole problem. Step one: a request hits LiteLLM's MCP Streamable HTTP endpoint carrying a Bearer token, any Bearer token. Any as in the advisory record literally says arbitrary? The GitLab advisory record dated July 22nd says the endpoint accepted an arbitrary Bearer token. Step two: LiteLLM tries to validate that token as one of its own keys, and it fails. Good. That's the system working. You'd think. But there's an OAuth2 pass-through fallback. When key validation fails, the code doesn't say no. It swaps in an empty user API auth object and keeps walking. Hold on. Empty? Like no user, no team, no permissions listed? Empty object. Nothing in it. Oh, man. So in plain terms, a failed check gets treated as a pass. The gate asks for ID, you hand it a napkin, it writes your name on a badge. Okay, but here's what I actually wanna know. What does an empty auth object get you? Because empty sounds like it should mean zero access. You'd think empty means nothing, except nobody wrote the rule that says nothing means stop. Step three, per the advisory, is that attackers could then list and call the MCP configured tools. List and call, so not just peeking at a menu. Right. Listing tells you what's wired up. Calling runs it. Whatever that gateway was configured to reach, that's your menu. And with a gateway, that's usually the good stuff: databases, internal APIs, whatever somebody bolted on at two in the afternoon. Picture it as two requests. The first one asks in effect, "What tools do you have?" And the gateway answers with the list. The second picks a tool off that list and asks the gateway to run it. Nothing in the chain stops either. So the attacker doesn't need to know anything in advance. The first answer writes the shopping list for the second. The creator brief for this episode puts it as a made-up bearer token opening an authenticated MCP session. Authenticated is doing a lot of lifting in that sentence. It really is. So who's affected, and what's the fix? Every version before one point eight four point o is affected. Version one point eight four point o fixes it. The advisory rates it CVSS eight point two high, weakness class CWE 287, improper authentication. Eight point two, but I've seen a different number floating around. The Hacker News reports it's an eight point eight. Same flaw, same endpoint, different score depending on who's holding the calculator. So don't argue about the decimal. Both say high, both say patch. Right. And the practical read of a score like that is triage order. High means it goes near the top of the pile, not that it waits for the next maintenance window. And since this one landed on a list of exploited bugs, the pile just got shorter. Patch first, argue about decimals later. Exactly. But the scary part, it sounds like any string at all walks in, and that's where it gets a little more careful than the headlines. Now the nuance then, because I've got a feeling that any string is carrying more than it should. Okay, so get this. There's a community detection template, a Nuclei one, that got tested against two LiteLLM builds, one point eight three point one four, and the patched one. Nuclei, like the scanner people run at three in the morning? That one. And the template's notes say a fabricated token starting with SK dash gets the tools list through on the vulnerable build. Starting with SK dash, so it looks like a real key. Right. And the notes also say the test ran with allow all keys set to true. Hold on. That's a config flag doing some work there. It is. In that setup, a random token without the SK dash prefix returned a five O O. So not literally any string. Not in that test. And on the fixed build, the fabricated token also returns a five oh oh, door shut. So how did the prefix and the flag work together? Does allow all keys make the SK shape the only gate? The notes don't say, and I'm not gonna guess at the code path. What I can tell you is what they observed. With that flag on, a key-shaped fake got through and a non-key shaped one got a five oh oh. Two observations, no theory. Okay, but one community template is one setup. I wouldn't tell anyone that every deployment behaves this way. Agreed. Other outlets say any token works, and the template author flags that disagreement. Nobody should treat either side as the whole fleet. Fine. Now the part I care about. Does somebody actually exploit this? The Hacker News reports that a cloud security vendor saw exploitation attempts against its honeypots. Honeypots. So attackers were poking at bait. Attempts, yes. Not a confirmed breach, and I'm not gonna dress it up as one. Fair. But it tells you scanners found the endpoint fast. Which brings us to your job. Pressure test me. Gladly. If it needs a token that looks like a key plus a particular flag, how much does the nuance change your risk? Not much. That's it? The check still failed open. Whether the attacker types SK banana or SK literally anything, the gateway took a failed validation and handed back a pass. A narrower trigger is still a hole. And SK prefixes aren't exactly secret. Anyone can guess the shape. Yes. Guessing a prefix is not a security control. Put it on a mug. And a config flag isn't a lock either since somebody has to remember what it's set to. That's the part I've watched go wrong in real teams. It only works if that flag is on. Turns into, "We're fine," in one meeting, and then nobody ever checks whether the flag is on. Switching gears because there's a bigger wrinkle. Everyone's calling this the first MCP bug on the KEV list. And us? Wait for it. One outlet says a June LiteLLM entry came before it. Oh, no. So is it really the first? Okay, so here's what the evidence says about first. The brief we're working from calls this the first MCP-specific bug on CISA's must patch list. The Hacker News complicates that. Complicates how? Before I get there, for the non-engineers in the audience, KEV is CISA's Known Exploited Vulnerabilities catalog. The name is the whole pitch. A listing is about bugs known to be exploited, not bugs that merely might be. Which is why people treat it as a to-do list, hence the must patch label. The Hacker News says an earlier LiteLLM flaw, CVE-two zero two six four two two seven one, was added to KEV around the same time. Same project, different bug. Around the same time. That's squishy. It is. The source doesn't give me an order I'd stick a claim on. So is that earlier one an MCP bug? The Hacker News doesn't say. It just notes the earlier CVE, and that's all I can tell you. Huh. And the June entry that one outlet points at? Right. Techinsider.org. As relayed by The Hacker News, it disputes the first framing. I haven't seen that outlet's own piece, so I'm treating it as a flag, not a verdict. Fair. So we say possibly first and move on. We say it's disputed, which is a weird place for a trophy to land, honestly. Nobody wants a participation ribbon for being the first gateway to wave strangers through. And notice who's wearing it. This is the same project the brief says was backdoored through Trivy back in March. Oh, man. LiteLLM again. Again. Supply chain compromise in the spring and now a gateway that accepts a made-up credential. I'd only vouch for that Trivy link as far as the brief states it. Sure. But if you're running it, that's two very different ways to lose your keys in one year. Very different. One needed somebody to sneak into the build pipeline. And this one needed nothing. No cleverness at all. Wait, back up. Careful with nothing. That test setup wanted a key-shaped token, so it needed something. Just very little. Fair. Almost nothing clever. And for a defender, the Trivy history says something too. You can't judge a project's trust at the build and ignore its front door. You need both covered. Which is my whole point. Go ahead. Say it. Whichever bug turns out to be first, the pattern is missing auth. Nobody had to trick a model. Nobody wrote a poisoned prompt. A request showed up, and the gateway never really asked who it was. Because the exotic stuff sells talks. Prompt injection gets the conference stage. And a failed check that quietly passes gets a footnote. Which is why I'd rather audit the boring door than the fancy attack. Boring doors are where the tools live. And speaking of boring doors, the same month had another one. Same month, same pattern. Grafana. Okay, so Grafana. The researcher's disclosure on the Pillar Security blog titled Valid But Never Issued says callers could invoke the MCP tools with no authentication at all. No login. Nothing. Nothing. And the tools ran using the server's own configured Grafana service account. So the caller shows up empty-handed and borrows somebody else's keys. Oh man, that's the part I keep chewing on. The server has credentials. The caller has none. Guess whose permissions get used? The server's every time. Very efficient. Zero onboarding. Then there's a second separate bug. A caller controlled destination turned the HTTP request tool into an SSRF. That's CVE-2026-19516, CVSS 9.1. Wait. SSRF as in I tell your server where to send a request, and it just goes? Right. The server takes a destination from the caller, and the server makes the call from inside its own network position. So the server is the confused deputy holding a badge and a map. Right. That's the textbook shape. A program with real authority gets talked into using it for someone who has none. The caller supplies the destination, and the server supplies the standing, and what that reaches depends on where the server sits. I don't have a list of targets from the write-up, so I'll only say this: anything that trusts that server's position is in play. And a nine-point-one is not a score you get for a typo. Fair. How many people are running this thing? The same write-up says the image has about one-point-nine million Docker Hub downloads. Hold on. Downloads isn't deployments. I'd bet plenty of those are somebody's laptop on a Tuesday. Agreed, and I'm not claiming one-point-nine million exposed servers. It's a measure of how far the image traveled, nothing more. Okay. And the fix? Here's the sad bit. Grafana shipped only optional bearer token protection in version one-point-one. Optional. Optional. So the lock exists. It's just in the box next to the door, which loops back to the title. A session can look valid without anyone ever having issued it. The server acts with its own credentials, not the caller's, so the question of who is asking never gets asked. And that rhymes with the LiteLLM mess. Different code, same hole. Nobody checked who was knocking. Which is the lesson of any tool holding its own credentials. The permissions in play are the server's, so the server's setup is the real security boundary. I've sat reviews where somebody says, "It's internal, so it's fine," and the whole room nods. Internal just means the only thing between you and the tool is whoever finds the port. Adversas's October roundup lists the Grafana session spoofing right next to the LiteLLM listing, so people are filing these in the same drawer. There's a third one in that pile too, right? The MCP Python SDK OAuth flaw? That's in the brief as the third example. I don't have details on it, so I'm not gonna guess at the mechanics. Smart. Better a blank than a made-up bug. Three projects, one month, one shape of problem. So you're probably wondering what you can actually do before Monday. Yeah. Now what to do about it. Okay, so the gateway's patched, hopefully. But Hive Security published a piece on September fifteenth with a title that stings: Your AI gateway is a cloud control plane. Control plane. Yeah, that's a bigger claim than one CVE. What's the argument? Hive Security points at four things together: the exploited MCP auth bypass, unsafe defaults, guardrails that can execute code, and pass-through routes with no restrictions. Their conclusion is that you isolate the gateway and run it like tier one infrastructure. Guardrails that execute code. The safety feature has a shell. Love that for us. I'm only reporting what Hive says, but the pattern holds. This box sits in front of your model keys and your tools, so it's a crown jewel wearing a sticker that says proxy. Okay, here's my checklist, and these are my recommendations, not Hive's claims. One, patch to one-point-eight-four-point-zero or later. Would that have stopped this bug? Yes, fully. It's the only item that closes the hole itself. Okay. Easy one. Next. Two, keep the gateway off the open internet. Put it behind a private network or a VPN. Would that have stopped it? Because an attacker who can't reach the endpoint can't send a made-up token. Right. It doesn't fix the bug. It shrinks who can try. Hmm. So that's a seatbelt, not a repair. A seatbelt is fine when the brakes are the unknown. Three, give each MCP tool its own scoped credential, not one broad service account behind everything. Wait, though, the bypass handed over an empty auth object. Scoped credentials wouldn't have blocked the request. Correct. The request still gets through, but what it can touch afterwards gets small. Blast radius, not front door. Fair. So it wouldn't have prevented the bug, but it would have changed the headline from owns the cloud account to read one dashboard, ideally. Ideally. Four? Two, log every tool call: who, which tool, what arguments, when. Stop it? No. That's a smoke detector. Right. No. But without logs, you find out from a CISA alert instead of your own alert, and unauthenticated sessions look odd in a log since nobody should be calling tools without an identity attached. Huh. So two items prevent, two limit damage, and one of those is just telling you the house is on fire. Still better than learning it from the neighbors. Hold on, though. If patching is the only item that actually closes the hole, why bother with the other three? Because patching only fixes the bug you know about. The other three are for the next one, and that four-part list from Hive suggests this box has more than one way to go wrong. Okay. That's the list. Last, the one thing to do Monday because if you only do one, I have a strong opinion about which one. Oh, I know which one. You're about to say it before I do. Okay, so you've got a Monday, a coffee, and exactly one job. Version check. Which version? One-point-eight-four-point-O. That's the fix. Every LiteLLM release before it is affected, so anything older than that number is a problem. Even the one nobody remembers installing? Especially that one. Somebody's weekend prototype is now a gateway holding tool credentials. Prototype with a pulse. Right. So here's the whole bug in one breath. A key check fails. A fallback shrugs and says fine. An empty auth object walks the request to your tools. And Grafana MCP is the cousin. No check at all, and the server just uses its own service account to do the work. Different door, same empty room behind it. So what's the actual assignment? Not a vague review things. Three moves. Find every LiteLLM instance you run, including the ones in containers nobody owns. Confirm each one is on one-point-eight-four-point-zero or later. And then the fun part. Send it a fabricated bearer token. On a fixed build, you should get an error, not a tool list. Wait. Why test if the version number says you're fine? Because a version string is a claim and a rejected fake token is evidence. And write down what you find: version, where it runs, who owns it. And if one turns out to be old? Then upgrade it first and ask questions after and rerun the same test. That's my part. Max, wanna close this out? Yeah. Go check. And when you find the forgotten one, remember that it was never the lock that was hard. Somebody just had to look at the door. New episodes land every Tuesday, so subscribe wherever you listen. And if this saved you from a bad deployment, leave us a review. Thanks for listening. Lock your doors, folks, especially the boring ones.