CVE-2026-79696: The First Real Agent-on-Agent Exploit, and What It Means for CI/CD Trust Boundaries

On September 9, researchers publicly disclosed CVE-2026-79696, a maximum-severity (CVSS 10.0) code injection vulnerability in Google's Agent Development Kit (ADK) for Python — the framework a lot of teams use to build and orchestrate AI agents. What makes it worth a closer look isn't the score. Plenty of bugs hit 10.0. What makes it worth a closer look is that this is one of the first documented cases of one AI agent successfully attacking another AI agent through a CI/CD pipeline, using the automation both agents were trusted to run.

If your team is building anything with agentic automation — and increasingly, everyone's team is — this is a preview of a failure mode you're going to see a lot more of.

What actually happened

ADK versions 2.0.0 through 2.6.0 shipped an adk web feature for replaying recorded test sessions, meant to help developers debug and iterate on agent behavior locally. The vulnerability is tracked as CWE-184, an incomplete list of disallowed inputs — the replay path didn't sufficiently restrict what a "test session" could contain, and a crafted replay payload could get executed as code rather than treated as inert test data.

On its own, that's a bad-but-contained local dev-tooling bug. The part that made it a CVSS 10 is where ADK got deployed: Google's own ADK repository ran GitHub Actions workflows — issue-analyze.yml, issue-fix.yml, pr-analyze.yml — that used ADK agents to automatically triage incoming issues and pull requests. Those agents read attacker-controlled text (issue bodies, PR content) as part of their normal job. An attacker who understood the replay flaw could craft an issue or PR that, when the triage agent processed it, executed arbitrary code on the GitHub Actions runner behind that workflow.

That's remote code execution, unauthenticated, on infrastructure with access to repo secrets and further automation — reachable simply by opening an issue. Google's fix wasn't a patch-and-move-on: they deleted the three vulnerable workflows outright and closed the underlying replay flaw. When a vendor's response to "here's the fix" is "we're just removing the automation instead," that tells you how much they trusted the surrounding controls.

Why this isn't just a normal supply-chain bug

Security teams already have a mental model for CI/CD supply-chain attacks: a compromised dependency, a leaked maintainer token, a poisoned build script. The controls for that are mature — pin versions, scope tokens, review diffs, sandbox runners. CVE-2026-79696 doesn't fit that model cleanly, because the vulnerable component wasn't a passive dependency. It was an active agent making decisions about untrusted input, and the exploit worked because the agent was doing its job correctly — reading the issue, trying to be helpful, running the replay it was told to run.

	Traditional CI/CD supply-chain attack	Agent-mediated CI/CD attack
Entry point	Compromised package, leaked credential, malicious commit	Ordinary, public-facing input (an issue, a PR comment) an agent is designed to read
Trust boundary that failed	Code review / dependency integrity	The agent's own judgment about what counts as "data" vs. "instruction"
Who has to act maliciously	An insider, or someone who compromises an insider's access	Nobody — any external user can trigger it
Typical mitigation	Signing, pinning, least-privilege tokens	Still being figured out — input sanitization for agents is not yet a mature discipline

That last row is the uncomfortable one. We have two decades of tooling and process for "don't trust unreviewed code in your pipeline." We have very little for "don't let your automation's judgment be the attack surface." The ADK case is effectively prompt-injection-adjacent, but with a twist: the payoff wasn't manipulated text output, it was code execution on a CI runner with real credentials attached.

What this means if you're hiring or training for security roles

We run hands-on labs and hiring assessments for a living, so we think about this less as "interesting CVE" and more as "what should a competent AppSec or platform engineer be able to spot before it ships." A few things stand out from this incident that are genuinely testable skills, not just trivia:

• Recognizing when "input" is actually "instruction." The core failure is a classic injection pattern wearing a new outfit. Anyone who's solid on SQL injection or command injection fundamentals should be able to reason about this even without AI-specific training — the shape of the bug is the same, the context is new.
• Scoping CI credentials to the blast radius you'd tolerate from an anonymous stranger. If a workflow processes public, untrusted input (issues, PRs, webhook payloads), its runner shouldn't hold any credential you wouldn't hand directly to that stranger. This was true before agents existed and it's still true now — the agent just made the gap easier to reach.
• Auditing what your automation is actually allowed to execute, not what it's supposed to execute. "The agent is only meant to summarize issues" is a description of intended behavior, not an enforced boundary. If the underlying framework can be coerced into running code, intent doesn't matter.
• Treating agent frameworks as part of your attack surface inventory, not just your feature roadmap. A lot of teams adopted agent tooling fast over the last year without folding it into the same threat-modeling process as any other CI dependency. This CVE is a concrete argument for closing that gap now rather than after an incident.

The honest takeaway

Strip away the "AI agent" framing and this is a familiar story: untrusted input reached a code path that shouldn't have trusted it, and the blast radius was wide because CI credentials were sitting right there. The novelty is that the untrusted-input-processor was itself an autonomous agent, which is a component category most security teams don't have a standard checklist for yet. That checklist is going to get written over the next year or two, one incident like this at a time. Teams that start testing for it now — in code review, in CI hardening, in the hands-on scenarios they train and hire against — are going to be ahead of a curve that's about to get a lot more crowded.