CVE-2026-115522: Cross-Application Artifact Namespace Isolation in Google Agent Development Kit (ADK) for Python
Exposure of Resource to Wrong Sphere (CWE-668) in FileArtifactService in Google Agent Development Kit (ADK) for Python (google-adk) versions 1.19.0 before 1.39.1 and 2.0.0a1 before 2.7.0 allows a caller in one application to list, read, overwrite, or delete artifacts belonging to another application when both applications share a FileArtifactService root directory and use the same userid (and sessionid for session-scoped artifacts). FileArtifactService accepted appname across its public API methods but omitted appname when constructing on-disk paths (root/users/{userid}/... instead of root/apps/{appname}/users/{userid}/...). Version 2.6.0 scoped writes by appname but retained a legacy root/users/{userid} fallback for reads and deletes; version 2.7.0 and the 1.x backport in version 1.39.1 removed the fallback and enforce full per-app path scoping.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
google-adkto a version that resolves this vulnerability.Fixed in 1.39.1 - Upgrade
Upgrade
google-adkto a version that resolves this vulnerability.Fixed in 2.7.0
Event History
Frequently Asked Questions
Which deployments are exposed to cross-application artifact access?
Deployments are exposed when two or more applications share the same FileArtifactService root directory and use the same user_id. Session-scoped artifacts also require the applications to use the same session_id.
What access does an attacker need to exploit this issue?
The attacker must be able to call FileArtifactService public API methods from one application while matching the affected user_id, and for session-scoped artifacts the session_id, used by another application sharing the same root directory. Under those conditions, they can list, read, overwrite, or delete the other application's artifacts.
Are version 2.6.0 deployments fully protected?
No. Version 2.6.0 scoped writes by app_name, but reads and deletes could still fall back to the legacy root/users/{user_id} path. Full per-application path scoping is enforced in version 2.7.0 and version 1.39.1.
How can I determine whether existing artifacts may be affected?
Check whether multiple applications have been configured to use a shared FileArtifactService root directory with overlapping user_id values, and overlapping session_id values for session-scoped artifacts. Artifacts stored under the legacy root/users/{user_id} path are relevant because affected versions omitted app_name from their on-disk paths.