Three Strikes in Five Months: What Google's ADK Security Failures Mean for Enterprise AI Agents

Google’s Agent Development Kit (ADK) is one of the fastest-growing tools for building AI agents — an open-source Python framework that has picked up roughly 20,000 GitHub stars and about 3.3 million downloads a month since its April 2025 launch, according to Firecrawl’s survey of open-source agent frameworks. It’s also had a rough 2026. Between April and September, ADK was hit by three separate, independently disclosed security failures — two of them unauthenticated remote code execution flaws rated a maximum CVSS 10.0, and one a real-world case of one AI agent tricking another into running privileged commands on Google’s own infrastructure.

None of these were theoretical. Each was found by outside researchers, each forced Google to ship a fix, and each targeted a different layer of the same product: the package itself, twice, and the automation Google used to maintain it. That pattern — not any single bug — is the part enterprise buyers should actually be worried about. If you’re evaluating agent frameworks for production use, or you’ve already shipped agents built on one, the ADK timeline is a useful case study in what “immature attack surface” looks like in practice, and what to check for before you commit.

A Timeline of Three Failures in Five Months

April: The First Unauthenticated RCE

On April 13, 2026, a critical vulnerability tracked as CVE-2026-4810 was disclosed in ADK for Python, affecting versions 1.7.0 through 1.28.0 and the early 2.0.0a1 pre-release. The flaw combined code injection with missing authentication controls, letting an unauthenticated remote attacker execute arbitrary code on any server running the ADK instance — whether deployed on plain Python, Cloud Run, or GKE. It carried a CVSS score of 9.3, and Google shipped patched versions (1.28.1 and 2.0.0a2) the same day it went public.

June–July: When One Agent Fooled Another

A few months later, researchers at Pillar Security documented what they describe as one of the first real-world cases of an AI agent being manipulated into attacking another AI agent inside Google’s own CI infrastructure, as reported by The Hacker News. The ADK GitHub repository ran automated workflows where a public-facing triage agent would analyze incoming issues and post a summary under a bot account. A second, more privileged workflow watched for a /adk-issue-fix command and, if it saw one, handed a code-writing agent broad credentials to act on the repository.

The problem: the privileged workflow checked who had posted the trigger comment, not whether the account posting it had itself been manipulated. An attacker could craft a GitHub issue with prompt-injection text that steered the triage agent into posting the trigger command itself — turning a low-privilege bot into a proxy for commands it never should have been able to issue. Researchers showed this could lead to arbitrary code execution on CI runners (via Git’s core.hooksPath and alias mechanisms) and exposure of the bot’s personal access token along with Google Cloud service-account credentials. Google removed the three affected workflows by June 9 and confirmed the fix on July 21, 2026.

September: The Second Unauthenticated RCE

Then, on September 9, 2026, a second maximum-severity flaw landed: CVE-2026-79696, a CVSS 10.0 code injection vulnerability in the adk web component, present in every ADK for Python release from 2.0.0 through 2.6.0 wherever pytest was installed alongside it — again across OSS, Cloud Run, and GKE deployments. The root cause, classified as CWE-184 (“Incomplete List of Disallowed Inputs”), was an incomplete denylist of standard-library modules reachable through a crafted test-session replay, letting an unauthenticated attacker execute arbitrary code. Google patched it in version 2.7.0, and the release notes quietly confirm the fix alongside several other hardening changes — blocking more of the standard library from agent-config code references, guarding the local API server against DNS rebinding, and redacting credentials from trace logs.

Why This Keeps Happening

Three incidents in five months isn’t proof that ADK is uniquely bad — plenty of fast-moving open-source projects accumulate vulnerabilities. What it does show is a pattern specific to agent frameworks: the same design choices that make them useful for automating work also expand what counts as an attack surface. A testing utility (pytest integration) became a remote-code-execution vector. A convenience feature for repository maintenance (bot-driven issue triage) became a privilege-escalation chain. And a denylist-based sandboxing approach — trying to enumerate everything an agent shouldn’t be able to reach — proved incomplete twice in the same codebase.

This is the same underlying issue we’ve flagged before with the explosion of machine identities running inside enterprises: every agent, tool integration, and CI bot is a credentialed actor that can be impersonated or tricked, and most organizations don’t yet track them the way they track human accounts (see our look at the non-human identity crisis). It also echoes what we found digging into credential leakage in AI coding tool ecosystems more broadly — see the skill marketplace blind spot — where the tooling around agents, not just the agents themselves, is where the real exposure tends to hide.

What This Means If You’re Building or Buying on Agent Frameworks

None of this means avoid ADK, or agent frameworks generally — it means treat “framework maturity” as a specific, checkable thing rather than an assumption. A few practical implications:

Patch cadence isn’t optional anymore

If your platform team adopted ADK 2.x for internal tooling, the gap between 2.6.0 and 2.7.0 wasn’t a routine version bump — it was the difference between an unauthenticated RCE and a closed one. Enterprises building on any agent SDK need the same patch-tracking discipline they apply to container base images and dependency scanning, not the ad hoc “update when convenient” habit many teams still have for developer tooling.

CI and automation credentials need agent-aware scoping

The June–July incident didn’t touch a single line of shipped code — it exploited how Google’s own team automated its GitHub repository. Any enterprise running agent-driven CI/CD, automated triage, or bot-assisted code review should assume that a public-facing, low-privilege agent can be manipulated into acting as a proxy for a higher-privilege one, and scope credentials accordingly rather than trusting an account identity alone.

Vendor security posture deserves the same scrutiny as model choice

We’ve written before about how vetting an AI vendor increasingly means asking about their own operational security, not just their model’s capabilities — see what OpenAI’s paused training run should change about how you vet AI vendors. The same logic applies to the open-source frameworks underneath your agents: check how fast a project’s maintainers disclose and patch, not just how popular the GitHub repo is.

Sprawl makes patching harder, not easier

The more agent frameworks, SDKs, and third-party tool integrations an organization accumulates, the more of these patch windows it has to track simultaneously — a problem we detailed in our piece on enterprises losing control of their own AI agent sprawl. A security team that doesn’t have a current inventory of which agent frameworks are running which versions, in which environments, can’t act on a disclosure like CVE-2026-79696 even if they see the advisory.

Actionable Takeaways

• Inventory before you patch. Know every environment running ADK — or any agent framework — and which version, before a CVE forces the question.
• Treat test and dev tooling as production attack surface. The pytest-linked flaw in ADK shows that “it’s just for testing” doesn’t mean it’s outside an attacker’s reach once it’s installed alongside a web-facing component.
• Scope automation credentials to the task, not the account. Bot identities that can be impersonated through prompt injection need the same least-privilege discipline as human service accounts.
• Ask vendors and open-source maintainers about disclosure speed, not just feature velocity. A same-day patch (as in the April CVE) is a good sign; a framework with no visible security advisory process is a red flag regardless of GitHub star count.
• Revisit your agent framework choice annually, not once. A framework that looked secure at adoption time can accumulate a very different risk profile a year later — as ADK’s 2026 has shown.

Frequently Asked Questions

Is Google’s Agent Development Kit (ADK) safe to use now?

The specific flaws disclosed in 2026 — CVE-2026-4810 and CVE-2026-79696 — are patched as of versions 1.28.1/2.0.0a2 and 2.7.0 respectively, and the agent-to-agent CI workflow issue was fixed by removing the affected GitHub Actions workflows. Running the latest patched release closes these known issues, but the underlying pattern (denylist-based sandboxing missing edge cases) suggests more hardening work is likely ahead.

What made CVE-2026-79696 a maximum-severity (CVSS 10.0) vulnerability?

It allowed an unauthenticated remote attacker to execute arbitrary code with no user interaction required, in any ADK for Python 2.0.0–2.6.0 deployment where pytest was installed — a combination of low attack complexity, no privileges needed, and full impact on confidentiality, integrity, and availability that maxes out the CVSS scale.

Was any of this exploited in the real world before disclosure?

No confirmed real-world exploitation has been reported for any of the three incidents. All three were found and reported by independent security researchers (GitHub-credited reporters for the two CVEs, and Pillar Security for the agent-to-agent CI exploit) before attackers are known to have used them.

Does this mean enterprises should avoid agentic AI frameworks generally?

Not necessarily — it means treating an agent framework’s security track record as a first-class evaluation criterion alongside its features and performance, the same way you’d evaluate a database or a message queue you’re about to put in production.

How is this different from a typical open-source vulnerability disclosure?

Two of the three incidents involve AI agents themselves as the attack mechanism — one agent manipulating another through prompt injection to gain elevated privileges — rather than a traditional software bug alone. That’s a newer class of risk that conventional dependency scanning doesn’t fully cover yet.

What should a security team do right now if they use ADK?

Confirm you’re on version 2.7.0 or later, audit any CI/CD automation that grants agents write access to repositories or credentials, and add ADK’s GitHub Security Advisories page to whatever feed your team already monitors for critical dependency alerts.

Sources

• CVE-2026-79696 Threat Intelligence Report - Technical breakdown of the September 2026 ADK code injection vulnerability, CVSS score, and patch details.
• Google Agent Development Kit (ADK) Code Injection and Missing Authentication Advisory - GHSA-rg7c-g689-fr3x - GitHub Advisory Database record for the April 2026 CVE-2026-4810.
• Google Deletes 3 ADK AI Workflows After Malicious GitHub Issue Could Trigger Privileged Agent - The Hacker News report on the agent-to-agent privilege escalation in ADK’s CI automation.
• Google Deletes ADK Workflows After Agent-to-Agent Injection - Cloud Security Alliance research note with the full incident timeline and Google’s response.
• Release v2.7.0 · google/adk-python - Official changelog confirming the security hardening fixes shipped alongside the September patch.
• The best open source frameworks for building AI agents in 2026 - Source for ADK’s GitHub star count and monthly download figures.
• AI agent security: the complete enterprise guide for 2026 - Enterprise-focused guidance on securing agentic AI deployments referenced for best-practice context.