🔥 CyberForge CVE of the Day #048 🚨 CVE-2026-79696 — Google ADK Web Agent Replay to Unauthenticated RCE This is an AI-agent RCE where the model never needs to make a bad decision. A YAML configuration chooses a Python callable. A saved test session supplies the recorded function call. The framework pulls the trigger itself. No prompt injection. No model jailbreak. No victim click. CVE-2026-79696 is a critical code-injection vulnerability in `adk web`, the development interface supplied with Google Cloud’s Agent Development Kit for Python. Its hand-built denylist missed execution-capable standard-library modules, allowing crafted YAML to resolve an unsafe callable and test replay to invoke it. Under the published vulnerable deployment conditions, an unauthenticated remote attacker can execute arbitrary code with Low attack complexity and no user interaction. Google assigns the maximum CVSS v4.0 score of 10.0 Critical. No exploitation in the wild or reliable standalone public PoC was confirmed at review time. CISA has not placed it in KEV. But Google’s public patch describes the missing control and reported replay path, leaving considerably less mystery for anyone studying the diff. ⚠️ If an affected `adk web` instance was reachable by untrusted users, remove that exposure, upgrade, rebuild, verify and investigate now—the lack of a public PoC is not a security boundary. 🔑 Key details: ⭐ Severity: Critical 📊 CVSS v4.0: 10.0 🧮 Vector: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/U:Amber` 🧠 Weakness: CWE-184 — Incomplete List of Disallowed Inputs 🧬 Attack pattern: CAPEC-242 — Code Injection 🎯 Targets: Google Agent Development Kit for Python / `google-adk` 🧩 Vulnerable boundary: YAML code-reference validation → tool resolution → saved-session replay 🌐 Attack vector: Network ⚙️ Attack complexity: Low 🔓 Privileges required: None 👆 User interaction: None 🔀 Scope: No v3.1 Scope metric published; v4.0 records High subsequent-system impacts ⚔️ Confirmed impact: Arbitrary code execution 💥 CVSS impact: High confidentiality, integrity and availability impact to vulnerable and subsequent systems 👤 Execution context: The `adk web` process/container and its workload identity 🛡️ Fix: Upgrade to `google-adk` 2.7.0 or later 🔑 Additional remediation: Do not expose `adk web` to a network; rebuild/redeploy workloads and investigate prior exposure 🚨 Active exploitation: Not confirmed 🧪 Reproduction: Vendor patch and regression test describe the path; no reliable standalone public PoC located 📋 CISA KEV: Not listed when checked 10 September 2026 📉 EPSS: 0.00437 — 0.437% at review time 🗓️ Earliest confirmed attacks: None publicly confirmed 🩹 Vendor patch: `google-adk` 2.7.0, released 13 August 2026 📜 Vendor bulletin: Google Cloud CNA record and official repository fix 🏷️ Researcher credit: Sanil Dulal 🔬 Campaign research: None publicly released for this CVE at the cutoff 🧬 What actually went wrong? Google ADK lets YAML configurations name tools, callbacks, schemas, models and integrations using fully qualified Python object names. The application identifies the top-level module, imports the object and connects it to executable agent behaviour. A name in YAML can therefore become a live Python callable. Vulnerable releases tried to control this with `_BLOCKED_MODULES`, a denylist of standard-library modules associated with operating-system access, process creation, networking, dynamic evaluation and other sensitive actions. The weakness was structural: the list named dangerous modules one by one. Google says missed objects could process supplied strings without constructor arguments, slipping through existing mitigations and running arbitrary code. 1️⃣ Unsafe configuration enters the resolver An attacker supplies agent YAML containing a Python reference. Because its top-level module is absent from the incomplete denylist, validation accepts it. 2️⃣ ADK turns the reference into a tool The loader resolves the callable and places it into the agent’s executable tool graph. 3️⃣ Test replay invokes the resolved callable Google’s regression test describes uploaded agent YAML followed by a saved test session whose recorded `functionCall` is dispatched directly to the resolved tool. The callable receives attacker-controlled content and code executes with ADK service authority. The fix uses `sys.stdlib_module_names` and built-in names to reject the whole standard library, while retaining explicit blocks for importable legacy and test-support modules. It replaces an incomplete list of "dangerous" names with a category-wide rule. No exploit payload, weaponised YAML, saved-session body or turnkey reproduction recipe is included here. 🤖 "AI-agent RCE" does not mean "the model was prompt-injected" The reported chain does not rely upon stochastic model behaviour. ❌ The model does not need to invent a malicious tool call ❌ The attacker does not need to jailbreak the model ❌ A user does not need to approve a generated action ❌ Prompt or output filtering does not repair the vulnerable resolver The call already exists in the crafted replay. Model-centred controls may never see the decisive action, so defenders must inspect configuration provenance, dynamic imports, replay permissions, application routes and process behaviour. ⚔️ The practical attack chain: 1️⃣ An attacker finds a network-reachable `adk web` deployment. 2️⃣ The service runs an affected `google-adk` version from 2.0.0 to before 2.7.0. 3️⃣ The environment meets Google’s stated condition that `pytest` is installed. 4️⃣ Crafted agent YAML supplies a code reference missed by the denylist. 5️⃣ ADK imports the object and resolves it as a tool. 6️⃣ A crafted saved session supplies a recorded call for that tool. 7️⃣ Replay dispatches it without a live model decision. 8️⃣ The resolved callable processes attacker-controlled content and code executes in the `adk web` runtime. 9️⃣ The operator may reach data, secrets and services available to the workload. 🔟 Further cloud, cluster or internal compromise depends upon IAM, mounts, metadata protection, egress and network reachability. Steps one through eight reflect the Google CNA record and public patch at a safe level. Steps nine and ten are realistic post-exploitation possibilities—not activity attributed to a known campaign. 👤 "Arbitrary code execution" does not mean automatic host root or Google Cloud project administrator. Successful code begins with the authority already held by `adk web`. Locally, that is normally the operating-system account running Python. In Cloud Run, it is the container plus its service identity. In GKE, it is the pod/container, Kubernetes service account and mapped Google Cloud workload identity. That context may still be able to: 🔹 Read source code, configuration and environment variables 🔹 Access mounted secrets, API keys and model credentials 🔹 Request service-account or workload-identity tokens 🔹 Reach internal databases, APIs and administrative services 🔹 Alter writable application or agent data 🔹 Launch child processes or use permitted cloud APIs 🔹 Pivot using stolen credentials or trusted network access The exact blast radius depends upon service-account IAM, Kubernetes RBAC, container privileges, mounted volumes, metadata access, secret management, network policy and egress controls. The CVE does not by itself establish container escape, root on a GKE node, Kubernetes control-plane compromise or administrator access across a Google Cloud project. 📦 Affected products and versions: 🔴 Google Agent Development Kit for Python 🔹 PyPI package: `google-adk` 🔹 Structured affected range: `>=2.0.0, <2.7.0` 🔹 Minimum fixed version: `2.7.0` 🔹 Later stable releases observed at review time: `2.7.1` and `2.8.0` 🔴 Named deployment contexts 🔹 Python OSS deployments 🔹 Cloud Run 🔹 Google Kubernetes Engine 🔹 Environments where `pytest` is installed The CNA prose says "versions 2.0.0 through 2.6.0", while its structured affected object says version 2.0.0 with `lessThan: 2.7.0`. That machine-readable boundary also captures the published 2.6.1, 2.6.2 and 2.6.3 releases. CyberForge uses the safer structured range: treat every 2.x release below 2.7.0 as affected until Google clarifies otherwise. Other ADK language implementations are not named in this CVE. Do not extend the finding to Java, Go, Kotlin or TypeScript without separate evidence. Inventory production, staging, CI, developer, DR, container, autoscaling and dormant revisions. A forgotten demo or old rollback image remains an attack surface. 🕰️ The quiet patch-diff window: 🟢 13 August 2026: Google publishes `google-adk` 2.7.0 with the commit that blocks the full Python standard library in agent-config code references. 🔵 25 August: CVE-2026-79696 is reserved. 🟢 26 August: `google-adk` 2.8.0 is published on PyPI. 🚨 9 September, 08:16 UTC: Google Cloud publishes the CVE record with a 10.0 Critical score and the 2.7.0 solution. 🔵 9 September, 09:17 UTC: NVD publishes its record and marks it Awaiting Analysis. 🔵 9 September, 20:29 UTC: CISA ADP records exploitation `none`, automatable `yes` and technical impact `total`. 🔥 10 September: CyberForge CVE of the Day #048 research cutoff. The fix preceded CVE publication by 27 days. That does not prove exploitation, but the root-cause clues were publicly diffable before defenders had a searchable identifier. The operational conclusion is simple: > An exposed pre-2.7.0 instance deserves investigation across its full retained exposure window—not merely from 9 September onward. Exposure is not proof of compromise. It is reason to preserve evidence and hunt before logs, revisions and replay artefacts disappear. 🦠 What attackers did after code execution: That information is not publicly confirmed. No authoritative source has published a campaign, victim count, payload, persistence, C2 or post-exploitation objective. CISA’s current exploitation decision is `none`. Investigate secret or token access, cloud/Kubernetes API use, internal discovery, altered source or agent data, new processes, unusual egress and sessions capable of retriggering behaviour. These are hunting hypotheses—not campaign findings. 🔎 No public campaign IOCs, what that changes: No Google, CISA or researcher source had tied public IPs, domains, files, hashes or malware to this CVE. There is no honest CVE-specific SIEM blocklist. Prioritise behavioural and exposure evidence: 🔍 Vulnerable version, `pytest` and untrusted `adk web` reachability 🔍 Unexpected YAML or fully qualified Python references 🔍 Replay following configuration changes 🔍 Abnormal process, file, secret, token or egress activity 🔍 Vulnerable historical revisions still receiving traffic CVE-labelled repositories may be copied advisories, scanners or unsafe code—not verified exploits. None was executed. An IOC miss cannot clear an exposed service. 👁️ Defender hunting guide: 1️⃣ Establish the exposure window Record version, image digest, deployment dates, reachability, authentication, `pytest`, process identity and workload permissions. Hunt from earliest retained exposure through verified fixed deployment, including the 13 August patch-diff window where possible. 2️⃣ Verify the actual runtime Run the check inside the container, virtual environment or image that serves requests: ```bash python -c "import importlib.metadata as m; print(m.version('google-adk'))" ``` Flag `>=2.0.0, <2.7.0`. A patched laptop or lockfile does not prove a Cloud Run revision or GKE pod loaded the fix. 3️⃣ Review ingress and application telemetry Search for: 🔍 Agent-configuration creation, upload or modification from unfamiliar sources 🔍 Saved test-session creation or replay outside normal development activity 🔍 Replay immediately following a YAML change 🔍 Unauthenticated requests reaching development functions 🔍 Import, validation or tool-resolution exceptions 🔍 Suspicious request → process, file, token or egress correlation No stable endpoint name or unique signature is public. Use route inventory and application context. 4️⃣ Inspect agent-generated data Review YAML history for references outside the application, `google.adk` and approved integrations. Scrutinise standard-library, legacy, profiler, debugger, tracing, timing and test-support families. Preserve suspect YAML and sessions before removal. 5️⃣ Hunt process and filesystem behaviour Investigate the `adk web` Python process for: 🔍 Shell, interpreter, package-manager or system-utility children 🔍 Reads of `.env`, credential, SSH, CI or mounted-secret material 🔍 Writes to source, startup, executable or configuration paths 🔍 Enumeration of environment variables, filesystems or metadata services 🔍 New outbound destinations or internal scanning 🔍 Crashes and restarts clustered around configuration/replay activity No child process is required for every malicious action; Python can access files, networks and APIs in-process. 6️⃣ Correlate Cloud Run and GKE control-plane evidence For Cloud Run, review request logs, revision routing, IAM invoker policy, service-account API activity, Secret Manager access and egress. For GKE, review Kubernetes audit logs, Secret reads, pod exec/attach, workload changes, service-account token activity, RBAC changes, DNS and network flows. Check whether vulnerable historical revisions, ReplicaSets or rollback images remained reachable after remediation. 7️⃣ Review identities and connected secrets Map every credential and identity available to the runtime. Look for old values used from new locations or against unusual APIs after patching. 8️⃣ Preserve the chain Retain ingress, application, process, DNS, egress and control-plane evidence alongside YAML, sessions, image digests, SBOMs and deployment specifications. Without campaign IOCs, chronology and correlation are the investigation. 🩹 Emergency remediation order: 1️⃣ Preserve evidence where operationally safe Capture request logs, configuration history, replay artefacts, process state, connections, cloud audit activity, image digests and workload permissions. Do not delay containment on a visibly compromised service merely to obtain perfect evidence. 2️⃣ Remove untrusted network exposure Stop the development service or place it behind strict network and identity controls. Google’s CNA guidance says not to expose `adk web` to a network. 3️⃣ Upgrade to `google-adk` 2.7.0 or later Prefer the latest compatible stable release. Resolve dependencies from controlled constraints and rebuild the deployment artefact. 4️⃣ Verify the running fix Check the version from the live Python environment. Confirm every pod, revision, worker and autoscaling source runs fixed code. 5️⃣ Rebuild and redeploy every source image Update Cloud Run revisions, GKE images, CI environments, developer containers, DR assets and rollback targets. Remove vulnerable revisions from traffic and prevent accidental reactivation. 6️⃣ Hunt the full exposure window Review YAML changes, saved-session replay, process behaviour, workload-identity use, secret access and outbound activity. 7️⃣ Rotate credentials where evidence warrants it Google does not mandate universal rotation for every vulnerable installation. Where code execution is confirmed or exposure cannot be bounded, revoke sessions and rotate accessible service-account keys, API tokens, model credentials, database secrets, CI/CD values and deployment keys at their authoritative source. 8️⃣ Rebuild and scope when compromise is confirmed Patching fixes the resolver. It does not remove persistence, reverse altered agent data or prove a previously exposed workload is clean. Rebuild from trusted patched sources and review connected cloud, cluster and internal systems when compromise is confirmed or cannot be bounded. 🧱 Temporary exposure reduction: The permanent fix exists. Compensating controls should support deployment—not replace it. ✅ Bind local developer instances to loopback where practical ✅ Remove public ingress and anonymous invocation ✅ Require strong authentication and authorisation for remote development access ✅ Restrict agent configuration and replay functions to approved developers ✅ Apply least privilege to Cloud Run and Kubernetes workload identities ✅ Block unnecessary metadata, Kubernetes API and internal-service access ✅ Constrain outbound traffic to approved destinations ✅ Use non-root containers, read-only filesystems and minimal capabilities ✅ Remove `pytest` and development-only packages from production images when unnecessary ✅ Alert on unusual child processes, token use, secret access and egress Removing `pytest` may reduce the published prerequisite, but it is defence in depth—not a substitute for upgrading. Authentication reduces unauthenticated exposure but does not repair the vulnerable resolution path for authorised, compromised or misconfigured access. 🚑 When vulnerability management becomes incident response. Escalate when: 🔴 Unfamiliar YAML code references appear on an affected instance 🔴 Saved-session replay follows an unexpected agent change 🔴 The ADK process launches unusual children or modifies application/startup data 🔴 Secret, metadata, IAM or Kubernetes API access departs from baseline 🔴 Unexplained egress or internal discovery follows a web request 🔴 Old vulnerable revisions receive traffic after the supposed fix 🔴 Agent definitions or sessions appear altered to retrigger behaviour 🔴 Logs are missing and responders cannot bound a high-privilege exposed workload Isolate the service, preserve evidence, revoke affected credentials, review workload permissions and scope connected systems. Do not claim container escape, node compromise, project administrator access, data theft, persistence or ransomware solely because a vulnerable package was present. Establish what executed and what the workload could actually reach. 📊 CISA KEV and EPSS context. At review time on 10 September 2026: 🔹 CVE-2026-79696 was not listed in CISA KEV 🔹 CISA ADP assessed exploitation `none` 🔹 CISA ADP assessed automatable `yes` and technical impact `total` 🔹 EPSS was 0.00437, or 0.437% Those signals describe the current evidence picture: no confirmed exploitation and a low early probability score. They do not alter the consequence of successful exploitation or make an exposed 10.0 service safe. EPSS predicts observed exploitation over 30 days; it does not score business impact or a particular deployment’s IAM blast radius. The stronger forward-looking signal is the public Google patch. It documents the incomplete denylist and the reported configuration-to-replay route, which may accelerate independent exploit development. 🧾 Evidence separation. Confirmed by Google Cloud / Google’s repository: 🔹 `adk web` contains a code-injection vulnerability 🔹 Affected range is structurally `>=2.0.0, <2.7.0` 🔹 Named contexts include Python OSS, Cloud Run and GKE where `pytest` is installed 🔹 Attack vector is Network, complexity Low, privileges None and interaction None 🔹 Successful exploitation allows arbitrary code execution 🔹 YAML code references were protected by an incomplete standard-library denylist 🔹 Saved-session replay can dispatch a recorded function call directly to the resolved tool 🔹 Version 2.7.0 blocks the full standard library and is the minimum fixed release 🔹 Vendor guidance says not to expose `adk web` to a network Confirmed by CISA ADP: 🔹 Exploitation `none` 🔹 Automatable `yes` 🔹 Technical impact `total` Researcher acknowledgement: Google credits Sanil Dulal as the reporter. No separate public technical or campaign report from the researcher was located at the cutoff. CyberForge interpretation: This is an orchestration-layer RCE, not a model-behaviour failure. The public patch lowers the effort required to understand the bug, and cloud workload authority can make process-level execution much more consequential than the container boundary first suggests. Not established: ❌ Exploitation in the wild ❌ A trustworthy standalone public PoC ❌ Internet-wide exposure counts ❌ The exact HTTP routes or original payload ❌ The precise role of `pytest` in the vulnerable chain ❌ Threat actor, victims or campaign objective ❌ Malware, persistence or command-and-control ❌ Automatic host, node, cluster or cloud-project takeover 🔥 CyberForge verdict: CVE-2026-79696 is a fresh, maximum-severity RCE in the web development surface of Google’s Python Agent Development Kit. It is Critical at CVSS v4.0 10.0. The published path is Network reachable, Low complexity, requires no privileges and needs no user interaction under the named deployment conditions. Its defining mechanic is the pairing of unsafe YAML code-reference resolution with deterministic saved-session replay. The AI model does not have to be fooled or persuaded; the vulnerable application can dispatch the recorded call directly. Code initially runs as the ADK process or workload identity—not automatically root, node administrator or cloud-project owner. But a service identity with secrets, broad IAM and internal reach can turn container-level execution into a serious cloud incident. No exploitation campaign or reliable standalone public PoC was confirmed. CISA has not added it to KEV, and the early EPSS score is low. The public Google patch nevertheless exposes enough of the vulnerable class and reported path to make passive waiting a poor strategy. The permanent repair is available, but upgrading alone cannot prove an instance stayed clean while exposed. The correct order is: 1️⃣ Preserve evidence where exposure makes compromise plausible. 2️⃣ Remove public or untrusted access to `adk web`. 3️⃣ Upgrade to 2.7.0 or later and rebuild deployment images. 4️⃣ Redeploy and verify the package loaded by every live runtime. 5️⃣ Hunt configuration changes, replay activity, process behaviour, secret access and egress across the full exposure window. 6️⃣ Revoke or rotate credentials where execution is confirmed or cannot be bounded. 7️⃣ Rebuild compromised workloads from trusted patched sources. 8️⃣ Monitor connected cloud, cluster and internal systems for follow-on abuse. The one-sentence CyberForge verdict: > The model never has to make the wrong call—CVE-2026-79696 lets an exposed ADK Web configuration choose the dangerous Python tool, then lets a crafted replay pull the trigger. 🔗 Google fixing commit: https://github.com/google/adk-python/commit/a16f6da3314b8dcd9925884cd6fc7fc9ffdd570d 🔗 Google ADK for Python v2.7.0: https://github.com/google/adk-python/releases/tag/v2.7.0 🔗 PyPI package and release history: https://pypi.org/project/google-adk/ 🔗 CVE record: https://www.cve.org/CVERecord?id=CVE-2026-79696 🔗 NVD vulnerability record: https://nvd.nist.gov/vuln/detail/CVE-2026-79696 🔗 CISA KEV catalogue check: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-79696 🔗 FIRST EPSS: https://api.first.org/data/v1/epss?cve=CVE-2026-79696 #CyberSecurity #CVE #GoogleCloud #GoogleADK #AgentDevelopmentKit #ADKWeb #AIAgentSecurity #PythonSecurity #CodeInjection #RCE #CloudRun #GKE #KubernetesSecurity #ThreatHunting #IncidentResponse #BlueTeam #SecOps #PatchNow #CyberForge
Post summary
CVE‑2026‑79696 is a critical RCE in Google ADK for Python that is fully patched in version 2.7.0, with no reported exploitation in the wild.
