CVE-2026-115522 in Agent Development Kit for Python
Summary
by MITRE • 10/28/2026
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 user_id (and session_id for session-scoped artifacts). FileArtifactService accepted app_name across its public API methods but omitted app_name when constructing on-disk paths (root/users/{user_id}/... instead of root/apps/{app_name}/users/{user_id}/...). Version 2.6.0 scoped writes by app_name but retained a legacy root/users/{user_id} 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified as CWE-668, Exposure of Resource to Wrong Sphere, represents a critical architectural flaw within the FileArtifactService component of Google Agent Development Kit for Python versions prior to 1.39.1 in the 1.x branch and prior to 2.7.0 in the 2.x branch. This security defect stems from an inconsistent implementation of resource isolation mechanisms that are fundamental to multi-tenant or multi-application environments. The core issue lies in how the service constructs file system paths for storing and retrieving artifacts, which are data objects managed by AI agents within the development kit. When multiple applications share a common root directory for their FileArtifactService instances and operate under identical user identifiers, the lack of proper application-level scoping allows one application to inadvertently or maliciously access resources belonging to another. This scenario is particularly dangerous in environments where distinct logical entities must maintain strict data boundaries, as it effectively bypasses intended isolation controls.
The technical root cause involves a discrepancy between the API contract and the underlying file system implementation. The FileArtifactService public API explicitly accepts an application name parameter for various operations, signaling to developers that resources are scoped per application. However, when constructing on-disk paths, the service historically omitted this app_name component from the directory structure. Instead of creating isolated directories such as root/apps/{app_name}/users/{user_id}, the system utilized a flat or user-centric path structure like root/users/{user_id}. This omission means that all applications sharing the same root and user ID write to and read from the exact same physical location on disk. Consequently, any operation performed by one application directly impacts the file state visible to other co-located applications using the same credentials.
The operational impact of this vulnerability is severe, encompassing a full range of unauthorized data manipulation capabilities. An attacker or compromised component within one application can list artifacts belonging to another application, effectively performing an information disclosure that violates confidentiality requirements. Beyond mere observation, the flaw allows for reading sensitive artifact contents, which may include proprietary logic, training data, or user-specific context crucial for agent functionality. Furthermore, the vulnerability permits overwriting and deletion of these external artifacts. This integrity violation can lead to denial of service conditions by destroying critical files or cause logical corruption if an application modifies another's state in unexpected ways. In a broader security context, this aligns with ATT&CK techniques related to Data Staged for Exfiltration or Defense Evasion through file system manipulation, as it allows lateral movement and data theft within the same host environment without requiring elevated privileges beyond those of the shared user account.
The remediation strategy involved a phased approach to path scoping that highlights the complexity of fixing legacy architectural decisions. In version 2.6.0, developers attempted to mitigate the risk by enforcing strict app_name scoping for write operations, ensuring new data was stored in isolated directories. However, this update retained backward compatibility features that allowed read and delete operations to fall back to the original insecure root/users/{user_id} path structure. This partial fix left a window of opportunity where an application could still access or destroy artifacts created under the legacy scheme by other applications. The issue was fully resolved in version 2.7.0 for the main branch and version 1.39.1 for the stable release, which completely removed the fallback mechanism. These versions enforce full per-app path scoping across all operations, ensuring that read, write, list, and delete actions are strictly confined to directories specific to each application name.
To mitigate this vulnerability in affected systems, immediate upgrade to version 2.7.0 or later for Python ADK is required. For organizations still relying on the 1.x branch, upgrading to at least version 1.39.1 is mandatory. If an upgrade is not immediately feasible due to dependency constraints, a temporary mitigation involves ensuring that applications sharing a FileArtifactService root directory do not use identical user_id values. By assigning unique identifiers to each application instance, even if the underlying path construction remains flawed, the overlap in file paths can be prevented, thereby restoring isolation at the operating system level. However, this is only a partial workaround and does not address the fundamental design flaw; therefore, patching remains the definitive solution. Developers should also audit their codebases to ensure that no custom implementations of artifact storage bypass these security controls by manually constructing insecure paths similar to the legacy behavior described in the vulnerability details.