Expand menu

Yesterday, September 9, Google Cloud published a vulnerability record acting as its own numbering authority. The identifier is CVE-2026-79696, and the official title Google gave it leaves nothing to interpretation: remote code execution in ADK for Python via an incomplete standard library denylist.

The CVSS 4.0 score is 10.0. There is no higher score.

I am writing about this because the number will travel on its own, and the number is not the interesting part.

What happened

The Agent Development Kit for Python is what a lot of teams are using to build agents on Google infrastructure. The flaw affects versions 2.0.0 through 2.6.0, in self-managed deployments, on Cloud Run and on GKE, with one condition: that pytest is installed in the environment.

The vector is as bad as vectors get. Network, low complexity, no privileges required, no user interaction. All three impacts on the vulnerable system — confidentiality, integrity, availability — are rated high, and so are all three impacts on subsequent systems. That last part is what pushes the score to 10.0: the compromise does not stop at the affected process.

Technically it is a CWE-184, an incomplete list of disallowed inputs. Someone tried to enumerate which standard library modules could not be invoked, and the enumeration came up short. An unauthenticated attacker executes arbitrary code by sending a crafted test session replay to the adk web interface.

Google's official remediation has two parts. First, upgrade to google-adk 2.7.0 or later. Second, verbatim: do not expose adk web to a network.

Why it matters

That second line is the story. Nobody writes “do not expose this to a network” about a tool that nobody is exposing to a network.

And there is one more detail, which is what actually made me sit down and write. Version 2.7.0, the one carrying the fix, was uploaded to PyPI on August 13. Its release notes make no mention of the flaw. The CVE that gives it a name and a score appeared on September 9: twenty-seven days later. For all of that time the patch existed and the advisory did not. The current version today is already 2.8.0, from August 26.

That is not negligence on Google's part — it is how coordinated disclosure works, and shipping the fix ahead of the advisory is exactly the right order. But it carries an operational consequence worth saying out loud: if your dependency update process is triggered by security advisories rather than by releases, you spent a month not knowing you had to move.

The enrichment that the United States cybersecurity agency added to the record completes the picture with three fields. Exploitation observed: none. Automatable: yes. Technical impact: total. That is the most uncomfortable combination available. There is no public exploit yet, the impact is complete, and when one appears it gets automated.

What it means if you run a technology company

There are three concrete readings here, and none of them is “update the package.” You already knew that one.

The first is image hygiene. The exploitation condition is that pytest is installed. In a properly built production image, pytest is not there. If your deployment is vulnerable, the CVE is telling you two things at once: that you use ADK, and that you packaged your development dependencies inside the container running in production. The second one is yours, not Google's, and it almost certainly is not limited to this package.

The second is surface area. Nearly every agent framework of this generation ships an inspection interface: to view traces, replay sessions, debug the call chain. That interface is born for localhost and ends up traveling inside the same container as the service. The jump from prototype to production, when it happens fast, does not remove that interface — it just changes its IP address. It is worth treating every debug panel in your stack as an exposed surface until someone proves otherwise.

The third is architectural, and it is the least comfortable. A denylist is a bet that you enumerated everything dangerous. It always fails the same way: someone finds the module that was not on the list. An allowlist fails closed — it breaks something legitimate and you find out in testing — while a denylist fails open, and you find out about that when it is already late. Anywhere your product executes something that came from outside, and an agent does precisely that all day long, that distinction stops being a matter of style.

My reading

I have spent months watching the same scene play out in conversations with teams: the agent works on someone's laptop, the result is impressive, and that same configuration gets pushed to the cloud because it is already working. Demo speed gets mistaken for deployment maturity.

This CVE does not say ADK is bad software. ADK is a serious tool and the report was handled correctly. What it says is that the developer tooling layer of the agent stack is currently the least audited part of everything we are putting into production, and also the part that changes most from version to version.

If I had to leave one question for your next technical meeting, it would be this: besides the service you actually meant to expose, what else is listening inside that container? On most teams, the honest answer is that nobody has checked since the day it first worked.