LLM Security Roundup, October 2026: Agents Trusting Agents, Open MCP Servers, and Hijacked Models

A lot happened in LLM security over the past month. Most of it wasn't new. Old bugs like SSRF, template injection, and unauthenticated APIs showed up again, this time in AI gateways and agent plumbing.

That's the theme of this roundup. If you build agents, the model is rarely the weakest part. It's what sits around the model: the protocols it talks over, the gateways in front of it, and the servers it trusts.

Here's what I read, what it means, and what I'd do about it.

Agents Trusting Agents: "Protocol Pivoting" Over MCP

Ars Technica reported on research by independent researcher Syed Anas Mohiuddin, who tested agents from organizations including Google, JP Morgan Chase, Rapid7, and the US federal government. His proof-of-concept attacks plant instructions in one agent, which then passes them to another internal agent as a normal delegated task. The second agent runs them because it trusts whoever handed it the work.

Two of the findings show the range. The Rapid7 bug, CVE-2026-97228, was rated only 2.7 out of 10 and has been fixed. The Google bug was rated 8. It came from Google's MCP Toolbox for Databases, which set up its HTTP client with no redirect policy and didn't validate target IP addresses. A crafted path parameter could make the toolbox follow a redirect to an internal endpoint. That's server-side request forgery. Google's fix added IP allow-lists and block lists, and now rejects an unsafe base URL at startup.

Mohiuddin calls the class "protocol pivoting." Markus Vervier of X41 D-Sec told Ars it's simply indirect prompt injection. I agree with Vervier on the label, but the naming debate isn't the point. Douglas McKee of Rapid7 put the lesson best: anything passed from an LLM to your tool should be treated like input from a stranger on the Internet.

Why it matters: inside an agent mesh, "internal" doesn't mean "trusted." If agent B accepts tasks from agent A without its own authorization check, agent B inherits every injection that reaches agent A.

MCP Marketplaces Have No Bouncer

OX Security analyzed 15,465 publicly indexed MCP servers across five registries, deduplicated to 5,095 unique hostnames. What they found:

• 15.6% of hostnames resolve to infrastructure outside the United States
• 0.45% route traffic through consumer tunneling services, mostly ngrok-free, which means they're likely running on someone's personal machine
• 2.3% no longer resolve, and six sit on expired domains that anyone could register for a few dollars a year. A new owner would inherit every agent still configured to call that server

They also make a point that's easy to miss: a remote MCP server can run backend code that differs entirely from its public repository. Reviewing the repo tells you what the developer published, not what the server runs.

Why it matters: adding an MCP server is a supply chain decision, the same as adding a dependency. Most teams aren't treating it that way yet.

GitLab AI Gateway: A 9.9 Template Injection

On October 2, GitLab disclosed CVE-2026-90970, rated 9.9, in its AI Gateway. A logged-in user with Duo Agent Platform access could escape the prompt template sandbox with a crafted custom flow configuration and run commands on the gateway host. It's fixed in gateway versions 19.2.4, 19.3.2, and 19.4.1. Only organizations that host their own gateway need to act; GitLab.com, GitLab Dedicated, and self-managed instances using a GitLab-hosted gateway are covered.

Two details stood out to me. First, it's a template engine flaw (CWE-1336), not a prompt injection. The attack lands before the model is ever called. Second, GitLab fixed another 9.9 gateway flaw of the same class, CVE-2026-1868, in February.

Why it matters: a self-hosted AI gateway holds signing keys and connects to both your source control and your model providers. It's a high-value box, and it deserves the patch cadence and monitoring you'd give any other critical server.

LLMjacking Grows Up: An Agent That Hijacks Your Model

Symantec published an analysis of an autonomous offensive agent it captured through an AI honeypot. The agent hunts for exposed LLM endpoints, then uses the hijacked model to plan and drive attacks: scanning, exploiting common web frameworks, stealing databases and credentials, and installing crypto miners. It was set up to run for up to 100,000 steps without human approval. The owner of the hijacked model pays for every step.

The request carried about 74 offensive tool definitions and a layered jailbreak. One layer reframed reading .env files and API keys as "normal development work" so the model wouldn't refuse. The honeypot itself logged more than 127,000 external requests from tens of thousands of unique addresses, mostly probing for model endpoints and spraying stolen API keys.

Why it matters: an unauthenticated model server, AI gateway, or MCP endpoint is something attackers actively scan for. Symantec's advice is basic and right: authenticate every path, treat AI API keys as high-value credentials, restrict outbound traffic from hosts that run agents, and watch for unusual inference spend.

The Bigger Picture: Google's Numbers on the AI Stack

Google Threat Intelligence Group's report on vulnerability trends in the AI era puts numbers behind all of this. GTIG tracked 2,076 AI-related CVE disclosures from January 2025 through August 2026, with more than 1,500 of them in 2026 alone. Agent orchestration frameworks, such as Flowise, Langflow, LangChain, and MCP, account for 50% of AI-related flaws.

Only a handful have been confirmed exploited in the wild. The examples GTIG lists include a command injection in LiteLLM's MCP server preview endpoint (CVE-2026-42271) and two Langflow flaws (CVE-2026-5027 and CVE-2025-3248).

The same report found that monthly vulnerability disclosures doubled in 2026, from 5,045 in January to 10,477 in July. Half of the vulnerabilities it could identify as AI-discovered lead to remote code execution, compared with 26% across the broader CVE ecosystem.

Why it matters: the AI stack is now normal attack surface, and the bugs in it are normal bugs. Your vulnerability management program should already cover your orchestration framework, gateway, and model server. If it doesn't, start there.

Worth Reading: OWASP's GenAI Red Teaming Manual

On October 20, the OWASP GenAI Security Project published the GenAI Red Teaming Manual Version 1.0. It lays out an eight-phase methodology, from planning and reconnaissance through exploitation, impact assessment, reporting, and remediation, and it covers models, applications, multimodal interfaces, and agents. If you've been asked to "red team the AI" and didn't know where to start, this is a good place.

What I'd Do This Week

If you build or run agents, here's my short list based on this month's news:

1. Authenticate agent-to-agent calls. Every agent should check authorization on the work it accepts, even from another internal agent. No implicit trust inside the mesh
2. Inventory your MCP servers like dependencies. Who runs it, where it's hosted, whether the domain is still yours, and whether a remote server's behavior matches its repo. Prefer servers you host yourself for anything that touches private data
3. Put an SSRF guard on every tool that fetches URLs. Validate destination IPs, control redirects, and block internal ranges and cloud metadata endpoints
4. Patch and monitor your AI gateway. If you self-host GitLab's AI Gateway, confirm the gateway version itself is 19.2.4, 19.3.2, 19.4.1, or later
5. Close exposed model endpoints. No unauthenticated model server, gateway, or MCP endpoint on the internet. Set spend alerts on AI API keys so a hijack shows up as a bill before it shows up as a breach
6. Restrict egress from agent hosts. An agent that can't reach the open internet can't scan it, call home, or download a miner

I wrote more about these controls in Securing AI Agents in Practice. This month's news didn't change the list. It just added more examples of what happens when a control is missing.

The Bottom Line

None of this month's big stories needed a clever new attack on the model. They needed an agent that trusted another agent, a server nobody vetted, a template engine without a real sandbox, or an endpoint without a password. That's good news. We already know how to fix those.

What did I miss this month? If you've seen an agent or MCP issue worth covering, send it my way on X.