Google disclosed a 10.0 ADK flaw today. The fix shipped 27 days ago.

Google published CVE-2026-79696 on 9 September 2026. Its remediation points to ADK for Python 2.7.0, released on 13 August. That is a 27-calendar-day gap between the release date and the public CVE date, calculated from the two records. It is not a measured period of exploitation.

The distinction changes the first question for an agent team. Before asking when a patch will arrive, establish which build is actually running and whether its development interface is reachable.

The 10.0 has deployment conditions

Google's CNA record assigns a CVSS 4.0 base score of 10.0. It identifies versions 2.0.0 through 2.6.0, the adk web interface, and environments with pytest installed. The described route is an unauthenticated crafted test-session replay leading to arbitrary code execution.

Those conditions belong in the headline's supporting paragraph. A package appearing in an inventory is a reason to investigate; it is not proof that every deployment exposes the vulnerable path. Equally, calling something a development tool does not make its listening socket private.

The two dates answer different questions

Record	Date	Meaning
ADK Python v2.7.0 release	13 August 2026	The version named in remediation was released
CVE-2026-79696 publication	9 September 2026, 08:16 UTC	The public CVE describes the vulnerability
Calendar-date difference	27 days, calculated	Not an exploitation duration or a patch deadline

The boundary sits before the model

The linked patch changes standard-library blocking for code references in agent configuration. The change moves from individually prohibited modules towards the standard-library module set. Its accompanying explanation is that apparently ordinary library functionality can also execute supplied code.

This is an input-validation problem in the software that hosts and develops an agent. A refusal instruction in a system prompt does not repair the Python configuration loader. A successful model evaluation does not establish that a replay endpoint is safe to expose. The controls have to meet the boundary that accepts the input.

The wider pattern is familiar from the site's discussion of MCP tool access: a convenient interface can carry more authority than its label suggests. Here the relevant authority is the host process accepting configuration and replay data. That connection is architectural; it does not imply that the two pieces describe the same vulnerability.

Check the interpreter that launches the service

A useful first evidence item is the installed package version in the actual runtime environment. On a workstation with several virtual environments, a version check in a different terminal can produce a reassuring but irrelevant answer.

The following is a read-only inventory command to run in the service's environment. It is an example for administrators, not output from a test performed on a vulnerable deployment here.

python -m pip show google-adk pytest

Keep the interpreter path, package version and deployment identifier together in the change record. Then check the launch command, listening address, ingress configuration and any reverse proxy that could make a locally intended service reachable elsewhere. A localhost binding on one process does not answer whether another component publishes it.

For a container, examine the installed packages in the running image rather than only the developer's lockfile. For a managed deployment, retain the image digest and revision that received traffic after the update. The point is to connect a release decision to the process users or other systems can actually reach.

The release notes contain an upgrade detail worth keeping

The 2.7.0 release notes also move pyarrow out of the gcp extra into bigquery-analytics. Teams using BigQueryAgentAnalyticsPlugin are directed to the corresponding extra. That is a compatibility consideration to include in upgrade testing, rather than a reason to leave an exposed development interface reachable.

Google's remediation has two parts: upgrade to 2.7.0 or later, and do not expose adk web to a network. Keep both in the work item. Treating the version bump as permission to publish a development interface would reverse the vendor's guidance.

An illustrative closure record would identify the old and new package versions, the running revision, the owner of the interface, and evidence that the unwanted network path has been removed. None of those fields needs a working exploit. They need an accurate view of deployment and reachability.

The position

The defensible response is to inventory the development surface as carefully as the deployed agent. Resolve the vulnerable version, verify the new runtime and remove network exposure of the development interface. Keep model safeguards in their own test plan, because they answer a different question.

The public CVE record does not establish observed exploitation. This briefing reads the record, release and patch; it does not claim a reproduced attack. That limit is compatible with urgent action on an exposed service, because the vendor's affected conditions and remediation are already specific enough to guide it.