The week's scariest ‘AI’ bugs weren't about AI. They were the confused deputy.

Read this week's security headlines in order and you would conclude that artificial intelligence has torn open a frightening new class of vulnerability. An AI connector in Grafana that hands its access token to a stranger. An Apache Camel integration where a manipulated model reply quietly rewrites what the server does next. A breach at an AI model host, a coding agent talked into opening a reverse shell, a browser extension coaxed into clicking around inside your inbox. The through-line writes itself: the machines are the new attack surface, and we need new defenses built for them.

We triaged those advisories alongside roughly 4,600 others this week, and the data points the other way. The scariest "AI" bugs of the week were not novel, and they were not really about AI. They were a thirty-eight-year-old flaw called the confused deputy, and the same flaw showed up in four other places this week that have no language model anywhere near them.

The story everyone told

The two AI-branded cases are real and genuinely nasty, so it is worth being precise about them. Grafana's MCP server (CVE-2026-15583, CVSS 8.6) can be told by an unauthenticated caller to send a request to a destination the caller picks, and it attaches its own Grafana service-account token on the way out. The token, and whatever internal endpoint that token can reach, come back to the attacker. The Camel case (CVE-2026-49042) is stranger still: a prompt-injected model reply sets hidden Camel headers through its tool-call arguments, steering the server toward code execution or an outbound request it never meant to make. Both are easy to file under "the AI did it," and both got filed there.

The same bug, minus the AI

Now set them beside the four other things we published this week. The @fastify/http-proxy package (CVE-2026-16117, CVSS 10) let a single URL-encoded character walk past the prefix rewrite that was supposed to keep internal upstreams hidden. Apache Camel's Solr routes (CVE-2026-48203) let caller-supplied HTTP headers slip past the header filter and become internal Solr parameters, forcing the server to call out on the attacker's behalf. Directus (CVE-2026-61836) cached responses under a key that omitted authorization, so with caching on it could serve one visitor's private data to the next. OpenShift's hosted control planes (CVE-2026-16242, CVSS 9.4) accepted connections into a private tunnel without validating the client certificate, letting a stranger join it and read control-plane traffic. Not a model in sight.

And yet all six are the same mistake. In 1988 the computer scientist Norm Hardy gave it a name: the confused deputy, a program that holds real authority and is talked into misusing it for someone who has none. The deputy is not malicious, and it is not broken in any way its own tests would catch. It simply trusts a piece of information the caller controls and treats it as though it came from inside the trust boundary.

Line the six up and the AI label falls off. Grafana trusted a destination header. Camel's Solr routes trusted a header prefix. Fastify trusted a URL prefix. Directus trusted a cache key. Hypershift trusted an unauthenticated connection. The langchain4j case is the only one where the caller happens to be a model, and even there the flaw is that tool-call arguments were accepted as internal headers. Two of six wear an AI badge, and the badge describes who was doing the talking, not what went wrong.

There is a structural reason intermediaries keep making this mistake, and it is not carelessness. A proxy, a gateway, an integration router, a cache: their whole job is to be faithful, to pass the request along without mangling it. Reproducing a caller's headers, honoring a caller's path, keying a cache the obvious way all feel like correctness. The security boundary and the transparency goal are in quiet tension, and the deputy resolves it in favor of transparency every time nobody drew the line explicitly. That is why the bug survives decade after decade in software written by careful people.

It is also not an artifact of which six we happened to write up. Server-side request forgery, the shape a confused deputy most often takes, was the fifth most common bug class we triaged this week: 105 of the roughly 4,600 vulnerabilities we logged a decision on, sitting just behind authorization and account-takeover flaws at 151. Around 84 of the week's items carried a sign of active exploitation, by our tracking. The confused deputy is not a museum piece. It is one of the busiest lanes on the road.

Where the trust actually breaks

This is the part the AI framing gets wrong in a way that costs defenders. All six break in the same place, and it is not the model, the plugin, or the payload. It is the forwarding step: the moment an intermediary decides where to go, or whom to believe, based on something the caller handed it, and then acts with its own privilege rather than the caller's.

Once you can see the flow, the remedy is unglamorous and identical across all six. The intermediary has to re-establish trust at its own boundary instead of inheriting it from the request. Re-validate the destination against an allowlist before forwarding. Bind the cache key to the identity of the requester. Verify the client certificate before admitting a connection. Filter the caller's header names so they cannot collide with your internal ones. This is the plain hygiene of a program that refuses to be anyone's deputy. It predates large language models by decades, and it would have closed every one of these holes, AI or not.

What to do, and what to watch

The correction is not "ignore the AI angle." Model-driven callers genuinely make the confused deputy easier to reach: a prompt injection can now be the thing that sets the malicious header, and MCP servers and tool integrations are brand-new deputies being wired into old systems at speed. The correction is about where you spend. A budget line for "AI security tooling" that leaves your proxies, gateways, and cache layers trusting caller-controlled metadata is money aimed at the costume, not the bug underneath it.

So patch the six if you run them. Fastify at CVSS 10 and Hypershift at 9.4 are the ones to move on first, and WordPress's unauthenticated wp2shell flaw is a separate must-patch from the same week. But patching a confused deputy closes this one instance and tells you nothing about whether the window was already used, and that is the part that should keep you up. From the intermediary's own logs nothing looked wrong; it did exactly what it was told to do. The signal lives one layer out. Watch your forwarding tier for egress it should never produce: a proxy or MCP server opening a connection to an internal address or a cloud-metadata endpoint it has no business reaching, a gateway resolving a destination that arrived in a request header, a cache handing an authenticated response to a session that never authenticated. Get those outbound decisions off the box and into something you monitor on its own, and alert on the deputy acting out of character rather than on the front door.

We made a version of this argument last week, when the week's most dangerous advisories were appliances that failed at authorization, and the week before, when the attack rode the trusted toolchain rather than the code inside it. This is the same lesson from a third angle. The object you would think to inspect keeps turning out clean. The trust around it keeps being the vulnerability. Name the deputies in your own stack, decide exactly what each one is allowed to be told, and you will have done more for next week's "new" bug than any product sold on the strength of the word intelligent.