Your AI Gateway Is the New Crown Jewel

On October 2, GitLab disclosed a 9.9 out of 10 vulnerability in its self-hosted AI Gateway. The attack is one crafted flow configuration.

An authenticated user with Duo Agent Platform access submits it, escapes the prompt template sandbox, and runs arbitrary commands on the gateway. That's CVE-2026-90970, and it's the cleanest example yet of why AI gateway security is now a first-class problem.

Nobody has reported exploitation in the wild. GitLab.com and GitLab Dedicated were patched before disclosure. If you self-host, you need 19.2.4, 19.3.2, or 19.4.1.

I'm not writing this to tell you to patch. You'll patch. I'm writing it because of what the bug is.

A Prompt Template Became an Execution Path

Strip the branding off and this is an old bug in a new place. The CVE weakness is CWE-1336: improper neutralization of special elements in a template engine.

That's server-side template injection. We've known about it for over a decade. The sandbox was supposed to make templates safe to render. It didn't.

What's new is where the template lives. It's a prompt template, inside a custom agent flow, which means the person writing it isn't an admin. It's any developer you gave Duo access to.

We spent two years treating prompts as text. Strings you tune, version, and argue about in pull requests. Then agent platforms started letting users define flows, and the prompt became a program that something on your server interprets.

Text that gets interpreted is code. The sandbox around it is the only thing standing between "a user's config" and "a shell on your infrastructure."

The Gateway Holds the Keys

Here's what makes the CVSS score make sense. The AI Gateway isn't a toy sitting off to the side.

It's the thing that brokers every model request. Per the reporting, a foothold there can expose JWT signing and validation keys, model provider credentials, and connection details back to the GitLab instance. From there, lateral movement is a question of network layout.

Think about what that means for your own stack. If you run any proxy that sits between your apps and your model providers, you've built the same thing. LiteLLM, a homegrown router, an MCP gateway, whatever.

I run one. Every n8n workflow I self-host that calls a model goes through a single place that holds provider keys. It's the most valuable box I own, and until this week I'd have described it as plumbing.

That's the pattern. The gateway looks like plumbing and holds the crown jewels.

The Uncomfortable Take

Everyone's focused on the prompt-injection threat model. Hostile text in an email tricks the agent into doing something dumb. That's real, and I wrote about the guardrail version of it in the post on agents with no framework-level checks.

But this bug needs no model at all. The model never gets involved. The attacker talks to the template engine directly, and the LLM is a bystander.

That's the part the industry keeps getting wrong. We're pouring effort into making models refuse bad requests, while the boring layer around the model, the config parser, the flow runner, the template renderer, ships with the same flaws every web framework had in 2014.

Your model's safety training does nothing for a bug in the code that loads its prompts.

And "authenticated user" is carrying a lot of weight in that advisory. In an enterprise, authenticated means thousands of people. Tell a company with 4,000 engineers that exploitation requires a login, and you've told them nothing about their risk.

Self-Hosted Doesn't Mean Safer

I'm a self-hosting evangelist. I run n8n on my own box, I keep my data off other people's servers, and I've said so loudly. I also said in the piece on running agents inside the firewall that the perimeter objection is dead.

This CVE is the other side of that coin. The hosted customers got patched before anyone published a thing. The self-hosters are the ones with a ticking clock, and they now have to know that the AI Gateway exists, what version it runs, and who can write flows.

Ask yourself honestly whether you could answer those three questions today.

I couldn't have, for my own setup, without checking. That's the cost of self-hosting nobody puts in the pitch. You own the patch cadence for components you didn't know you were running.

What I Changed This Week

Nothing dramatic. Four small things, all done in an afternoon:

• Inventoried every service that holds a model provider key. I found three, not the one I expected.
• Scoped each key to the narrowest spend limit and project the provider allows, so a leaked key is an annoyance instead of a bill.
• Put the gateway behind an allowlist so only my workflow host can reach it.
• Cut who can define custom flows or edit prompt configs down to me.

That last one matters most. If a config format gets interpreted, treat write access to it like write access to code. Review it the same way.

# Quick audit: who holds provider keys on this box?
grep -rIl --include='*.env' --include='*.yml' -E 'OPENAI_API_KEY|ANTHROPIC_API_KEY|GEMINI_API_KEY' ~/services 2>/dev/null

Ten seconds, and it's the most useful command I ran all week.

The Next Ten Bugs Look Like This

Expect more of these. Every agent platform now has some version of user-defined flows, user-defined tools, and user-defined prompt templates. Each one is an interpreter. Each interpreter has a sandbox that somebody wrote in a hurry during a race to ship agents.

The researcher who found this one reported it through HackerOne and got it fixed before it hit the news. That's the good outcome. The same week, Google paused vulnerability submissions to its open source reward program because AI-generated junk reports were burying maintainers. The signal is getting harder to find at exactly the moment the attack surface is growing.

So the defensive work lands on you. Know where your gateway is. Know who can write to it. Assume the sandbox leaks.

Patch the gateway. Then go find the one you forgot about.