Google Agent Mesh: unauthenticated peers could invoke MCP tools
Two missing-authorization flaws let an outsider join Google's Agent Mesh or skip its policy check, then call tools on connected MCP servers.
· GitHub Advisory Database · Research by Eli Ainhorn (Noma Security), Yanchon918s
Google Agent Mesh, an open-source mesh for MCP and A2A agents, received two critical CVEs on October 19, 2026 for flaws fixed in September: an unauthenticated peer could enroll itself and call tools on connected MCP backends.
01What happened
The National Vulnerability Database and the GitHub Advisory Database published CVE-2026-103091 and CVE-2026-102503 on October 19, 2026, rating both 9.3 under CVSS v4. Google's Agent Mesh project had already disclosed and fixed both flaws in September. Eli Ainhorn of Noma Security reported the enrollment chain, and Yanchon918s reported the ingress bypass.
02How it works
Missing authorization is the shared weakness. The control plane served its OIDC settings from an unauthenticated GET /info, accepted any valid provider token at POST /register with no claim filtering and no ban check, then applied a default policy that granted sam:system:authenticated a wildcard over every service and target. Separately, a node exposed its backends on a parallel /libp2p-http route that never verified a Biscuit token, so any peer able to dial the node reached the same handlers the MCP protocol path guards.
03Who is affected
Deployments below v0.1.0-alpha.9 carry the enrollment chain, and those below v0.1.0-alpha.3 carry the ingress bypass. Google's advisory states that the official deployment configuration shipped the wildcard policy, so default installs were exploitable, and that the shipped 0.0.0.0 libp2p bind with DHT discovery left nodes reachable. The current release is v0.1.1.
04What to do
Upgrade to v0.1.0-alpha.9 or later, which fails closed by default, requires explicit policy bindings at enrollment and adds ban checks. Replace any wildcard binding of sam:system:authenticated with explicit per-service bindings. Re-run dependency scanners against the github.com/google/sam Go module, because the CVE ids are new and earlier scans had nothing to match.
Questions people ask
- Am I affected if I run Google Agent Mesh with the default configuration?
- Default Agent Mesh installs below v0.1.0-alpha.9 were exploitable, because Google's advisory says the official deployment configuration shipped a policy granting sam:system:authenticated a wildcard over all services and targets. Every enrolled member therefore passed authorization. Operators who kept that shipped policy and never upgraded remain exposed, so check the running version before assuming the defaults were safe.
- Which Agent Mesh version fixes CVE-2026-103091 and CVE-2026-102503?
- Version v0.1.0-alpha.9 fixes the enrollment chain behind CVE-2026-103091, and v0.1.0-alpha.3 fixes the /libp2p-http ingress bypass behind CVE-2026-102503. Upgrading to v0.1.0-alpha.9 or later covers both. Google describes the alpha.9 fix as a fail-closed default policy, explicit policy bindings required at enrollment, and ban checks added to the registration path.
- Why do these CVEs appear now if Google fixed the flaws in September?
- Google published both advisories on its own repository on September 4 and 6, 2026, before any CVE id existed. The National Vulnerability Database and the GitHub Advisory Database assigned and published the two ids on October 19, 2026. Dependency scanners and SBOM tools match on CVE ids, so an Agent Mesh deployment that scanned clean last week can start reporting these findings.
Sources 5 links, all fetched
- 1github.comCVE-2026-103091
- 2github.comCVE-2026-102503
- 3github.comEnrollment Advisory
- 4github.comIngress Advisory
- 5github.comAgent Mesh v0.1.1