A Perfect 10 Against Google's Agent Stack: ADK Web UI RCE (CVE-2026-79696) Explained

On September 9, 2026, a CVE landed that security teams rarely get to see in the wild: a genuine, textbook CVSS 4.0 base score of 10.0 — the absolute maximum — against one of the most widely deployed agent frameworks in production. The target is Google Cloud’s Agent Development Kit (ADK) for Python, and the flaw, tracked as CVE-2026-79696, lets an unauthenticated remote attacker execute arbitrary code against the adk web developer UI on versions 2.0.0 through 2.6.0, in Python (OSS), Cloud Run, and GKE environments — wherever pytest happens to be installed.

If you build agents on Google’s stack, this is not a theoretical entry in a scanner queue. It is a pre-auth remote code execution primitive on the very tool your engineers run daily.

What the CVE actually says

The official description is unusually specific about the attack path:

“A Code Injection vulnerability in adk web in Google Cloud Agent Development Kit (ADK) for Python versions 2.0.0 through 2.6.0 on Python (OSS), Cloud Run, and GKE environments where pytest is installed allows an unauthenticated remote attacker to execute arbitrary code using a crafted test session replay.”

Every clause in that sentence matters:

• adk web is ADK’s local/development web UI — the browser-based console where developers configure, chat with, and evaluate agents. It is a FastAPI server, and it ships with the CLI.
• “test session replay” is the injection vector. ADK’s evaluation tooling can replay recorded sessions as tests — a legitimately useful feature for agent regression testing. The vulnerability means a crafted replay payload is interpreted as executable code rather than data.
• “where pytest is installed” is the environmental trigger. pytest is the most common Python dev dependency on earth, and it is present in an enormous fraction of container images that also bundle ADK — including CI images, evaluation pods, and “temporary” Cloud Run deployments that quietly became permanent.
• “unauthenticated” + “remote” is why the CVSS 4.0 vector reads AV:N/AC:L/AT:N/PR:N/UI:N with high impact across every dimension — vulnerable system and subsequent systems (SC:H/SI:H/SA:H). No privileges, no user interaction, network-reachable, trivial complexity. That combination maxes out the score. (Under the older CVSS v2 rubric it still lands at 7.5.)

How the allowlist failed: the anatomy of a denylist bug

The fix commit referenced by the CVE — a16f6da3314b8dcd9925884cd6fc7fc9ffdd570d, merged August 7 and shipped in the v2.7.0 release on August 13 — tells the story with disarming honesty. ADK’s agent configuration files (YAML-based configs for declarative agents) can reference Python callables for tools and callbacks. To keep that powerful mechanism from becoming a code-execution backdoor, ADK maintained a denylist of “dangerous” standard library modules.

Denylists fail by omission, and this one failed exactly the way you would predict. From the commit message:

“The denylist for YAML code references named dangerous standard library modules one by one, so anything it missed stayed reachable: it had profile but not cProfile, pdb but not bdb, trace, timeit or pydoc. Several of those execute a string you hand them and need no constructor args, so naming one as a tool or callback slipped past both existing mitigations and ran arbitrary code.”

Read that again: cProfile, bdb, trace, timeit, and pydoc all accept (directly or transitively) a string and execute it. Naming one of them as a “tool” in an agent config bypassed both existing mitigations. The patched version stops playing whack-a-mole entirely and blocks the whole standard library via sys.stdlib_module_names, allowing configs to reference only the agent’s own package and google.adk itself.

This is the same class of bug that keeps recurring in tool-calling and plugin systems: an execution feature (configure callables by name) is “protected” by enumerating bad things instead of enumerating allowed things. Every agent framework shipping YAML/JSON-configurable code references should treat this CVE as a free audit finding.

This is not ADK’s first rodeo

Context matters for triage. CVE-2026-79696 is the latest in a string of security incidents around Google’s agent toolkit:

• CVE-2026-4810 (April 2026, CVSS 9.3): code injection plus missing authentication in ADK versions 1.7.0 through 1.28.1, letting unauthenticated attackers hijack AI agents deployed on GKE and Cloud Run.
• CVE-2026-79707 (disclosed early September 2026): a path traversal flaw in the builder endpoint affecting ADK 1.9.0–1.21.0.
• A series of hardening commits through 2026 — gating builder endpoints behind a web flag, enforcing allowed file extensions, blocking RCE via nested YAML configurations, guarding the local API server against DNS rebinding, and disabling dev endpoints for production deployments on Agent Engine and Cloud Run.
• Separately, Pillar Security documented agent-to-agent privilege boundary failures in Google’s own ADK repository CI, where a low-privilege AI agent tricked a maintainer agent into running privileged commands — a reminder that the threat model now includes the agents themselves.

The pattern is consistent: adk web and its dev/builder endpoints keep ending up on the front line precisely because they are rich, permissive, and everywhere. A dev server that can load arbitrary agent code is, functionally, a code-execution service with a chat interface.

What you should do right now

1. Upgrade to ADK for Python ≥ 2.7.0 (2.8.0 is current, released August 25). The fix has been in the release line for nearly a month; the CVE publication on September 9 is what turns it from “should patch” into “will be exploited.”
2. Inventory your exposure honestly. The pytest condition means the vulnerability hides in images you don’t think of as servers: eval harnesses, CI runners, notebook images, prototype Cloud Run services. Search for google-adk and adk web/adk api_server invocations across registries and repos.
3. Kill network-reachable dev servers. adk web was never meant to be internet-facing. If it is reachable from outside localhost — or from a broader VPC than it needs — that is the actual root cause the CVE is exploiting.
4. Scan for the technique, not just the version. If you run ADK 2.0.0–2.6.0 anywhere, check agent configs for references to standard library modules used as tools or callbacks. The patched runtime blocks them; unpatched ones may already have them in place.
5. Check Google-managed surfaces. Google has stated it patches cloud-hosted instances directly, but self-managed OSS, GKE, and Cloud Run deployments are on you.

The bigger picture: agent frameworks are the new CMS

A decade ago, the highest-volume RCE targets were content management systems — PHP applications with plugin architectures that let administrators inject code by design. Agent frameworks are structurally repeating that history, with two accelerants: their configs are meant to reference executable logic (tools, callbacks, skills), and their operators assume the tooling is “just a dev thing” while deploying it on cloud infrastructure with real credentials attached.

A CVSS 4.0 score of 10.0 with no authentication requirement, no user interaction, and full impact on subsequent systems is the industry’s way of saying the default deployment posture of a major agent framework is untenable. Google fixed the specific bug a month ago; the systemic lesson — default-deny for code references in agent configs, dev servers that refuse to bind publicly, and evaluation features that never cross the trust boundary from data to code — is still being written, one perfect-10 CVE at a time.