Google’s Agent Toolkit Had a Perfect-10 Flaw

CVE-2026-79696 was published on September 9 against Google Cloud's Agent Development Kit for Python. Public advisories rate it 10.0 on CVSS v4.0, the maximum: reachable over the network, low complexity, no authentication, no user interaction, and full compromise of the host. Most businesses reading this do not run it. The mistake that caused it is one nearly all of them are making somewhere.

What the flaw is

The affected component is adk web, in google-adk versions from 2.0.0 up to but not including 2.7.0. The exploit condition is a vulnerable adk web deployment with pytest installed in the runtime, and the advisory calls out OSS Python, Cloud Run and GKE environments that meet it. Under those conditions, an unauthenticated remote attacker can run arbitrary code by submitting a crafted test session replay.

The mechanism is worth following, because it is not exotic. ADK lets you define an agent in a YAML configuration file, including which functions the agent may call as tools. Allowing arbitrary Python functions there would obviously be dangerous, so the loader blocked a list of dangerous standard library functions.

The list was incomplete. It missed several standard library functions that can execute code as a side effect, including cProfile.run, timeit.timeit and trace.Trace.run. None of those is named "run arbitrary code," which is precisely why they were missed. An attacker supplies a configuration naming one of them as a tool, replays a saved test session, and ADK's replay logic dispatches the recorded call directly to the resolved function.

The fix in version 2.7.0 blocks the entire Python standard library from being referenced in agent configurations, rather than maintaining a list of the bad parts. That change from a denylist to something closer to an allowlist is the core repair for this bug. It does not turn untrusted agent configuration into a safe input class: technical analysis of the patch notes that third-party package references can still be resolved, so who is allowed to supply YAML, and which packages resolve, remain live questions.

If you might be running it

ADK is a developer toolkit, so no business installs it by accident. The realistic route into your stack is a contractor or an internal developer who built an agent on it. Ask them today whether google-adk appears in any dependency list and at what version.

If the answer is yes and the version is anything below 2.7.0, upgrade to 2.7.0 or later, preferably the latest patched release rather than the minimum fixed version. Until that is done, the published guidance is to keep adk web off the network, restrict it to trusted internal or local environments, and avoid running it anywhere pytest is installed. There is no public reporting of exploitation in the wild that I have seen, which is a reason to move promptly rather than a reason to relax.

If you have no idea who to ask, that is the more important finding, and it is the problem we set out in vulnerability management without a security team.

Listing the bad things never finishes

A denylist enumerates what is forbidden and permits everything else. An allowlist enumerates what is permitted and forbids everything else. The first is comfortable to write, because you start from a working system and subtract the obvious dangers. The second is uncomfortable, because you start from nothing and have to justify each addition.

The asymmetry is that a denylist has to be right about every dangerous thing that exists, including the ones invented after you wrote it. An allowlist only has to be right about the things you need. This is a predictable failure mode of denylists rather than evidence of careless engineering. timeit.timeit is easy to leave off such a list because timing code is not what anyone pictures when they think about remote code execution.

Where you are making the same choice

This design decision shows up all over an ordinary business, usually without anyone recognising it as one.

Agent permissions. "The agent can do anything except delete records and send external email" is a denylist, and you will discover the third thing you should have excluded after it happens. "The agent can read these two tables and write to this one" is an allowlist and it is not much harder to write.

AI tool policy. A list of banned tools is out of date the week it is written, because a new one launches every few days. A list of approved tools is easier to review and maintain when the permitted set is small, and requests to add to it tell you what people actually need. It still needs revisiting when a tool changes behaviour or expands its permissions. That is why the framework in an AI governance framework for a small business is built around approval rather than prohibition.

Data rules. "Do not put customer data, financial data or HR data into AI tools" leaves every category nobody thought of on the permitted side. "Only public and internal information goes into AI tools" covers the categories you have not imagined yet.

System access generally. The same logic underpins least-privilege access for staff and contractors, and it is the reasoning behind the scoping approach in three boxes for an AI agent.

Why agent frameworks make this sharper

Traditional software does what a developer wrote. An agent framework exists to let a configuration file decide, at runtime, which functions get called, which is a deliberately wide door. Widening the door is the product, so the question of who may walk through it carries more weight than it did in software where the answer was fixed at build time.

Two things get blurred whenever a story like this appears. This is an ordinary software defect in a developer tool, not a model behaving unexpectedly, and it is unrelated to the agent incidents we covered in agents running a website for six weeks. Treating a coding bug as evidence that AI is out of control produces the wrong response, which is usually paralysis rather than a version bump.

One question this week

Take whichever AI agent or automation your business already runs, and ask whoever set it up a single question: is its access described as a list of what it can do, or a list of what it cannot. If the answer is the second, converting a narrowly scoped automation may be a short piece of work, though legacy permissions can take considerably longer. It is worth starting with whichever one touches customer data.

Frequently Asked Questions