Google ADK Web RCE: Can A Test Replay Run Code?

September 9, 2026

Google says a crafted test-session replay could run code on vulnerable ADK Web servers. See who is affected, what changed, and what to do.

Yes—Google says a crafted test-session replay could let an unauthenticated network attacker execute arbitrary code on a vulnerable Google ADK Web server. CVE-2026-79696 affects Google Agent Development Kit (ADK) for Python releases before 2.7.0 when pytest is installed. Google assigned the code-injection flaw a critical 10.0 CVSS score.

The finding is narrower than “Google AI agents can be hacked.” The vulnerable component is adk web, a local-development server. The attack needs that server to be reachable over a network, and Google's own code now warns that its endpoints are unauthenticated and must not be exposed to untrusted or public networks.

Operators should upgrade to Google ADK for Python 2.7.0 or later, redeploy the fixed artifact, and remove any direct network exposure. A version update closes the documented path; it does not prove that a previously exposed server was never accessed.

Research cutoff: September 9, 2026. This article separates Google's CVE record and source-code fix from the exposure and exploitation questions that remain unanswered.

What Is Confirmed

Google Cloud's CVE record for CVE-2026-79696 calls the issue “Remote Code Execution in Google ADK for Python via Incomplete Standard Library Denylist.” Its affected-version data marks Google ADK for Python 2.0.0 through versions earlier than 2.7.0 as vulnerable.

Google describes the required conditions this way:

• the target runs the adk web development server;
• it uses a vulnerable Google ADK for Python version;
• pytest is installed in that environment;
• the service is reachable by the attacker over a network; and
• the attacker sends a crafted test-session replay.

Under those conditions, Google says an unauthenticated remote attacker can execute arbitrary code. The record names open-source Python installations, Cloud Run, and GKE as affected environments. Its CVSS 4.0 vector lists a network attack with low complexity, no privileges, no user interaction, and high impact to confidentiality, integrity, and availability.

Google's prescribed fix is direct: upgrade to google-adk 2.7.0 or later and do not expose adk web to a network. The official 2.7.0 release includes the security change under the understated bug-fix description “block the whole standard library in agent-config code references.”

What Is Still Unclear

The public material reviewed for this article does not establish:

• exploitation against a real ADK deployment;
• a public proof of concept from the reporter;
• how many vulnerable adk web instances were reachable;
• whether any affected server exposed source code, test data, credentials, cloud identities, session records, or artifacts;
• a complete set of request, process, or file indicators for incident hunting; or
• whether every vulnerable deployment had pytest installed.

Google's CVE record was published September 9, while the referenced 2.7.0 release dates to August 13. The release notes do not label the fix with the CVE number. That means an operator who only scanned the changelog for “CVE” or “RCE” could have missed its security significance.

The absence of a published exploitation report is not proof that no exploitation occurred. It means exposure must be checked from each deployment's own version, package inventory, network configuration, and logs.

How Could A Test Replay Turn Into Code Execution?

The documented path combines a permissive code-reference feature with a replay mechanism that can dispatch recorded tool calls.

ADK agent configuration can name Python objects—such as tools or callbacks—using fully qualified module references. Before the fix, the loader tried to reject dangerous modules with an explicit denylist. That list blocked familiar names such as os, subprocess, and profile, but it did not cover every standard-library route that can execute a supplied string.

Google's fix commit identifies examples including cProfile.run, timeit.timeit, and trace.Trace.run. The commit explains that these functions could receive code without needing constructor arguments, so naming one as a tool or callback could pass the existing checks and run arbitrary code.

The new tests document the reported route more specifically: an attacker uploads agent YAML whose tool is cProfile.run, then replays a saved test session whose recorded function call dispatches to that resolved tool. The patch blocks the Python standard library as a whole rather than trying to enumerate every dangerous function individually.

That is an important distinction. The test replay did not somehow teach the language model a new exploit. It supplied data to a development feature that resolved a callable and then invoked it. The security boundary failed in deterministic application code.

Why Does pytest Matter?

Google's CVE description explicitly limits the vulnerable condition to environments where pytest is installed. The public record does not explain every internal dependency in that precondition, so it would be a mistake to treat any ADK installation as automatically exploitable through this exact path.

It would be equally risky to assume pytest is absent because it is “only a test dependency.” Development images, broad dependency groups, copied virtual environments, CI-derived containers, and convenience-focused builds often carry test packages into long-running systems.

Check the actual runtime image or environment. A lockfile, source repository, or developer laptop is not reliable evidence of what a Cloud Run revision, GKE pod, or remote development server currently imports.

Removing unnecessary test dependencies is useful defense in depth, but it is not a substitute for upgrading. The vulnerable code-reference policy still exists in older ADK versions, and Google's remediation is version 2.7.0 or later.

Was adk web Supposed To Be Public?

No. Google's current source documentation calls adk web a local-development server and says its endpoints are unauthenticated.

The official security-warning commit says any client that can reach the underlying API can read and write sessions, memory, and artifacts and run agents for any user or app. For adk web, the warning is stronger: development-only endpoints can read and write agent files and run evaluation and debugging code.

Google says to run it only on a trusted network, such as one bound to localhost, and never expose it to an untrusted or public network. If an API server must serve multiple users or extend beyond the local machine, Google says it needs the operator's own authentication and authorization layer.

“Intended for localhost” does not guarantee “only reachable from this computer.” Common exposure paths include:

• 0.0.0.0 or another non-loopback bind;
• Cloud Run or Kubernetes ingress;
• a reverse proxy or tunnel;
• editor and development-container port forwarding;
• an SSH forward;
• an overly broad firewall rule; or
• a shared internal network where every client is implicitly trusted.

An internal address is not an authentication system. If an untrusted device, browser, workload, or compromised service can reach the port, the server's lack of identity checks still matters.

Does Version 2.7.0 Eliminate Every Code-Reference Risk?

No—and Google's patch says so plainly.

Version 2.7.0 blocks imports from the Python standard library and retains explicit blocks for older or shimmed modules that may remain importable. That closes the documented standard-library bypass without requiring Google to predict each dangerous function added in future Python releases.

But ADK configurations can still resolve third-party packages by name. The commit says the change “narrows the surface rather than closing it.” That compatibility choice allows legitimate integrations to work, but it means agent configuration remains trusted code-like input.

Treat YAML, evaluation sets, test sessions, plugins, packages, and agent definitions as part of the executable supply chain. Authentication on the server prevents arbitrary outsiders from submitting them; review and provenance controls help prevent trusted accounts or repositories from introducing dangerous references.

This is the same broader lesson behind a malicious Git folder triggering code before approval: a file that looks like project data can cross into an execution path when a tool assigns it authority.

What Should Google ADK Operators Do Now?

Use the REPLAY check to separate patching from proof of safety.

R — Record The Real Runtime

Identify the installed google-adk version inside every running environment, not only in source control. Confirm whether pytest is importable and record the image digest, Cloud Run revision, or GKE workload that produced the result.

E — Eliminate adk web Network Exposure

Stop or firewall vulnerable instances first. Audit bind addresses, ingress, proxies, tunnels, load balancers, port-forwarding tools, and development environments. If remote access is genuinely necessary, place the appropriate server behind authentication and authorization rather than publishing adk web directly.

P — Patch And Redeploy

Upgrade to Google ADK for Python 2.7.0 or later, rebuild from a trusted dependency set, and deploy the new artifact. Restarting an old container or changing a requirements file without rebuilding does not replace vulnerable code.

L — Look For Evidence

Review HTTP access logs, proxy and ingress records, test-session replay activity, agent-file changes, unexpected tool definitions, child processes, shell commands, outbound connections, and writes outside the intended workspace. Preserve evidence before pruning logs or replacing the environment.

A — Audit Reachable Authority

Inventory the credentials, service accounts, tokens, source repositories, session data, artifacts, databases, and network services available to the process. If suspicious execution is found—or evidence is insufficient after meaningful exposure—rotate reachable secrets and investigate the host or workload as potentially compromised.

Y — Yield Verifiable Proof

After redeployment, verify that the running instance reports the fixed version, no public route reaches adk web, and unauthorized requests fail at an external authentication boundary. Use a safe synthetic configuration to confirm prohibited standard-library references are rejected; do not replay exploit code against production.

Is This The Same As The Earlier Google ADK Confirmation Flaw?

No. CVE-2026-79696 concerns code injection through agent-config references and a crafted test-session replay. It is not the earlier ADK issue involving forged tool confirmations in manipulated session history.

The two flaws do share a design lesson: recorded agent state is not passive text when the framework later uses it to authorize or dispatch actions. Replay data, tool-call history, confirmations, and configuration need integrity controls appropriate to the power they exercise.

That lesson also applies beyond ADK. A recent DeepSeek Harness sandbox escape showed how a development agent could reach a more powerful local control plane and disable its own restrictions. Different bug, same architectural question: can lower-trust content reach a component that has authority to execute code or rewrite policy?

What Does This Mean For Private AI Use?

Privacy risk is shaped by capability, reachability, and stored authority—not just by whether the model is local or hosted.

A local development agent may keep some data on your own infrastructure, but it can also sit beside source trees, test fixtures, shell tools, cloud credentials, and network access. A hosted conversational product involves remote processing, yet may expose far fewer workstation-level capabilities. “Local” and “private” are not synonyms, as the private AI chat versus local AI comparison explains.

Choose the narrowest system that can do the job. If the task needs autonomous code execution, build around containment, authenticated control planes, least-privilege credentials, and disposable environments. If the task only needs conversation, drafting, file analysis, search, voice, images, or video, adding a public development server and shell authority may create risk without adding useful value.

Where OpenVeil Fits—And Where It Does Not

OpenVeil is a privacy-focused hosted AI workspace for adults. Normal chat history is stored in the user's browser, and OpenVeil does not use prompts, uploads, images, audio, selected local history, or outputs to train foundation models. Active requests still require processing by OpenVeil and necessary providers.

OpenVeil is not a Google ADK patch, development-server firewall, code sandbox, vulnerability scanner, or incident-response product. It cannot secure an exposed adk web instance or determine whether one was compromised. It does not promise fully offline or anonymous operation, zero logs, no provider processing, HIPAA compliance, or protection from unrelated device and network risks.

The fit is deliberately narrower: OpenVeil gives adults a private conversational workspace without requiring them to operate an unauthenticated agent-development server or grant an assistant autonomous shell and repository access. Reducing capabilities you do not need cannot eliminate every privacy risk, but it can reduce the number of powerful boundaries that must hold.

Frequently Asked Questions

What Is CVE-2026-79696?

CVE-2026-79696 is a critical remote-code-execution vulnerability in Google ADK for Python's adk web development server. Google says an unauthenticated network attacker can execute arbitrary code with a crafted test-session replay when a vulnerable version runs in an environment with pytest installed.

Which Google ADK Versions Are Affected?

Google's affected-version data marks Google ADK for Python 2.0.0 through versions earlier than 2.7.0 as affected. Upgrade to 2.7.0 or later.

Is Google ADK Web Authenticated?

Google's current source warning says the adk web and API-server endpoints are unauthenticated. adk web is intended for local development on a trusted machine and should not be exposed to untrusted or public networks.

Was The Vulnerability Exploited In The Wild?

No reviewed public source establishes real-world exploitation as of September 9, 2026. That is not proof an exposed instance was untouched; operators need their own network and host evidence.

Does Removing pytest Fix The Vulnerability?

It removes a condition Google names for this specific exploit path, but Google's recommended remediation is still to upgrade to version 2.7.0 or later and keep adk web off the network.

Does OpenVeil Protect A Google ADK Server?

No. OpenVeil is a hosted conversational AI workspace, not an ADK security control. Its relevant advantage is avoiding an agent-development server and autonomous local code execution when those capabilities are unnecessary for the user's task.

The Bottom Line

Google's CVE record confirms that a crafted test-session replay could become unauthenticated remote code execution on a network-reachable, vulnerable adk web server with pytest installed. Upgrade to 2.7.0 or later, redeploy the fixed artifact, and keep the development server off untrusted networks.

The lasting lesson is broader than one denylist: test data becomes executable authority when a framework resolves and dispatches code references, and a local-development server becomes a remote target the moment tooling makes it reachable.