A CVSS 10.0 in an agent framework is a different kind of vulnerability

On 9 September a vulnerability carrying a CVSS score of 10.0 was disclosed against Google Cloud's Agent Development Kit for Python. Maximum severity: network-attackable, no privileges, no user interaction, total loss of confidentiality, integrity and availability.

Ten-point-zero is rare enough to be newsworthy on its own. What deserves more attention is that the scoring framework producing that number was not designed for the class of software being scored.

CVSS measures blast radius on a static system

The CVSS model asks what an attacker gains by exploiting a component: access to this host, these credentials, this data. It assumes the compromised component has a bounded and enumerable set of privileges, because conventional software does.

An agent framework does not. Its privileges are the union of every tool it has been granted, every credential in its execution context and every downstream system those credentials reach — and that set is defined at runtime by configuration, not at build time by code. Two deployments of the same framework at the same version can have blast radii that differ by orders of magnitude.

The score is therefore not wrong so much as under-determined. For a framework, 10.0 is the score of the worst plausible deployment, and your deployment may be far better or considerably worse.

For agent infrastructure, severity is a property of your configuration, not of the CVE.

Patching is necessary and not sufficient

Upgrade, obviously, and quickly. But a framework vulnerability that grants execution inside the agent's context has already told you something that survives the patch: whatever that agent could reach, an attacker could reach. That fact does not go away when the version number changes.

The remediation work that actually reduces exposure is the work you should have done at design time. What tools does this agent hold? What credentials are resident in its environment? What is the furthest downstream system reachable through them without a second authorisation? Most teams cannot answer those questions for their own deployments, which is why a framework CVE turns into an incident-response exercise rather than a patch cycle.

The disclosure gap is going to get worse

Conventional dependency scanning tells you which version of a library you are running. It does not tell you what that library was permitted to do in your environment. As agent frameworks proliferate, the gap between those two facts becomes the dominant source of unmanaged risk — and it is invisible to every tool currently in the average security stack.

The practical control is unglamorous: maintain a tool-and-credential manifest per agent, reviewed like a firewall rule set, with an owner. When the next framework CVE lands — and it will, because this software is young — the manifest is what turns a week of frantic archaeology into an afternoon of scoped remediation.

Written by the Devence Lab research team.