al-ice.ai

The Second Path Had No Gate: Two 9.3 CVEs in Google’s AgentMesh

AI Vulnerabilities & CVEs by al-ice.ai Editorial

At 03:16:58Z on 19 October 2026, 184 milliseconds apart, NVD received CVE-2026-102503 and CVE-2026-103091: two critical, CVSS 4.0 9.3 vulnerabilities in Google’s OSS Agent Mesh (google/agentmesh, the repository still referenced in both CVE records under its old name, google/sam; ~1,100 stars, Apache-2.0, created April 2026) — the libp2p mesh that federates MCP servers, A2A agents and inference endpoints behind Biscuit capability tokens issued by a central control plane. Both CVEs were assigned by Google’s own CNA function, both carry the maximum confidentiality/integrity/availability impact with no privileges and no user interaction, and both describe the same architectural failure from opposite ends: a mesh whose authorization boundary was enforced on one path while a parallel path to the same tools ran without it. We read both CVE records, both repository advisories, the fix commit and both fixed releases first-hand.

CVE-2026-102503: the ingress that skipped the biscuit check

A SAM node exposes its registered backends — MCP, A2A and inference services, including command/stdio-backed MCP servers — over two libp2p paths. The MCP-protocol path is wrapped in WithBiscuitAuth -> Authorize, which evaluates the caller’s Biscuit token against the node’s policy. The parallel /libp2p-http ingress, StartIngressServer in cmd/sam-node/node.go, reached the same backend handlers with no authorization check at all: any peer that could dial the node, with no enrollment and no valid Biscuit, could invoke any registered backend tool. The advisory documents the omission as source-exhaustive — a tree-wide scan found WithBiscuitAuth wired to exactly one production handler, the MCPProtocolID stream — and as runtime-confirmed on 10 June 2026: from an un-enrolled peer holding only a fresh libp2p keypair, a JSON-RPC call for a deny-listed tool returned HTTP 200 and executed over the ingress while the identical call over the MCP path was rejected.

The ceiling is what makes this more than a policy bypass. For command-backed services the ingress writes attacker-controlled JSON-RPC straight to the backend MCP subprocess’s stdin (exec.Command(cmd[0], cmd[1:]...)), and for URL-backed services it reverse-proxies to the backend target — so the defect is simultaneously unauthorized tool invocation, a potential remote-execution primitive, and an unauthenticated proxy into internal services. The reporter submitted it at 9.8 and documented a 10.0 scope-changed ceiling; Google published 9.3. The shipped defaults — a 0.0.0.0 libp2p bind with DHT discovery on the public testnet, a connection gater that is a ban-list only (“Layer 3 & 4 will handle the rest,” except on this path there is no Layer 3 & 4) — are what put AV:N under the score. The fix, commit 433bc99 (“Fix security gap in HTTP Datapath ingress and proxy token leak,” PR #171, +1,016/−576 across some fifty files), enforces VerifyBiscuitToken on every ingress request and strips and re-stamps the identity header before proxying downstream. First patched release: v0.1.0-alpha.3, 6 August 2026 — roughly ten weeks before the CVE.

CVE-2026-103091: open enrollment behind a wildcard default

The second CVE is the enrollment-side twin. GET /info on the control plane discloses the OIDC configuration with no authentication; POST /register accepts a JWT from the configured provider and auto-enrolls the caller as a mesh node with no approval, no invitation, no claim filtering and no ban check — the OIDC client is public, so any valid token from the provider works. Enrollment alone would be containable if the default policy were tight. It was the opposite: the shipped configuration binds sam:system:authenticated to allowed_services: [“*”] and allowed_targets: [“*”], and the SystemAuthenticated policy compiles to an unconditionally true Datalog rule. Every enrolled member therefore passes authorization for every service, and combined with open enrollment, any OIDC identity receives a mesh credential with full read, write and execution access across all backend nodes. Bans do not help — they are keyed on a peer ID derived from a local keypair the attacker regenerates — and a single one-hour OIDC token mints a 90-day mesh credential, so one enrollment outlives its token by three months.

The attached proof of concept, run end to end across two machines against the project’s own Dex OIDC broker, is unusually concrete for a repository advisory: the attacker script reads .env files holding API keys and database passwords, reads AWS IAM credentials, exfiltrates a database backup containing customer PII, deletes the backups, overwrites .env with attacker-controlled values and plants a reverse shell — all real file operations on the target host. Credit goes to Eli Ainhorn of Noma Security. The alpha.9 release notes (7 September 2026) list “3 security fixes and advisory published” alongside the fail-closed policy work; affected versions are alpha.1 through alpha.8, fixed in alpha.9 and later — roughly six weeks before the CVE.

What to do

Both fixes predate their CVEs by weeks to months, so the exposure window belongs to operators who tracked the alpha line without reading the security releases: upgrade to at least alpha.3 for the ingress bypass and at least alpha.9 for the enrollment chain — in practice, the current v0.1.0 (16 October) and v0.1.1 (18 October) releases, both of which postdate the fixes. Upgrading is not the whole job for the second CVE: any enrollment minted under the wildcard default should be treated as a full-mesh credential, so rotate mesh credentials, audit the enrollment list for identities that were never approved, replace wildcard policy bindings with explicit per-service grants, and do not expose the control plane’s /info and /register endpoints to networks you have not vetted. The pattern to carry elsewhere is the one the advisories state plainly: when a system grows a second route to the same capability — a new ingress, a compatibility endpoint, a debug path — the authorization gate must be re-wired, not assumed. The MCP path was tested to deny; the ingress was never asked.

Neither CVE is in the CISA KEV catalogue (checked 19 October 2026, 1,748 entries), and no exploitation has been reported — unsurprising for alpha-releases software, and not a reason to leave a 90-day credential minted under a wildcard policy unrotated.

Our verification was read-only. Both identifiers, publication timestamps (2026-10-19T03:16:58Z), Received status, Google CNA source, CVSS 4.0 9.3 vectors, CWE assignments and references were read first-hand from the NVD 2.0 API; the ingress omission, runtime confirmation, scoring discussion and fix routing from repository advisory GHSA-r6hp-67wp-c7jx; the enrollment chain, default-policy quotations, PoC operations and researcher credit from GHSA-cgmg-9xf6-rrgw; the fix scope, file list and line counts from commit 433bc99 and the alpha.3 and alpha.9 release notes; repository metadata (google/agentmesh, renamed from google/sam, 1,116 stars, 184 forks, Go, Apache-2.0, created 21 April 2026) and the current v0.1.0/v0.1.1 releases from the GitHub API. KEV status was checked directly. Brave Search was used for discovery only and returned no independent technical analysis beyond automated CVE mirrors. We installed nothing, enrolled no node, dialed no peer, and executed no proof of concept.

Sources: