Agent Router's MCP proxy let anything on the pod network skip gateway auth

If you run Envoy AI Gateway, which now calls itself Agent Router, upgrade to 1.2.1. The project published six advisories on Friday, and the worst (GHSA-mgwh-j6v5-5mf8, CVSS 8.1, rated high) is painfully simple: the MCP proxy in the external-processor sidecar listened on every interface on port 9856. Anything that could reach a Gateway pod could call it directly, skip the authentication Envoy enforces in front of it, and set the identity headers the proxy trusts, which also puts any credentials the gateway injects for backends within reach. A second advisory (6.8) let an MCP session created on one route be reused on another to get around that route's per-tool JWT rules. I found no report of exploitation so far.

What to do: upgrade to 1.2.1 (there's no 1.1.x patch), and until you can, add a NetworkPolicy that blocks ingress to port 9856 on Gateway pods. If anyone who shouldn't hold it could read your Gateway pod specs, rotate the MCP session seed after upgrading, because another of Friday's advisories says the sidecar still received it as a command-line argument. My take: AI gateways are turning into the place we park every model key and MCP credential, and a sidecar that trusts headers while listening on all interfaces is the mistake we spent years beating out of service meshes. These were published as repository advisories, so don't count on your package scanner to flag them.

The best read of the weekend is Radware's census of hidden prompt injection on GitHub, published Nov 5. Across roughly 143 million issues, pull requests and comments, the researchers found 2,281 AI-directed hidden-text cases and 47 real attacks. That's about one attack in 3.3 million items, but they're aimed: 56% go after the maintainers' own triage, review or CI bots, and 44% try to steal the bot's secrets, like a hidden comment in openai/codex telling the issue labeler to call a webhook and dump environment variables. The rate more than doubled from June to September. What to do: give issue-reading bots read-and-label tokens only, keep secrets out of jobs an outsider can trigger, and check who wrote a marker before a bot obeys it. My take: the 1,519 friendly markers projects use to steer their own agents worry me more than the attacks, because anyone can type them.

JetBrains' Junie coding agent shows the same CI risk from the vendor side. CVE-2026-123852, published by NVD on Friday, says that before version 1.8.0 the Junie GitHub Action allowed code execution with the workflow's credentials via fork updates. If your workflows pin Junie to an older tag or commit, move them to 1.8.0 or later today, and treat any fork-triggered run that touched secrets as worth a look in your Actions logs.

Two quieter items for anyone running their own AI stack. TorchServe picked up CVE-2026-123974 on Friday, covering every version: a predictable extraction directory in /tmp lets a local user swap a model's handler and run code as the TorchServe service account. The pytorch/serve repository is archived, so no fix is coming; run it in its own container or with a private /tmp (systemd's PrivateTmp=yes) and plan your move to a maintained server. And pypdf, the parser under a lot of RAG document loaders, shipped 7.0.0 with fixes for several medium-rated memory-exhaustion bugs triggered by crafted PDFs, including GHSA-59jv-x5x2-gg4c. If a dependency holds you below 7, parse untrusted uploads in a worker with a hard memory limit.