CVE-2026-115522
Exposure of Resource to Wrong Sphere (CWE-668) in FileArtifactService in Google Agent Development Kit (ADK) for Python (google-adk) versions
CVSS
—
Sin CVSS
EPSS
0.4%
p32
KEV
—
Exploit Today
10
0-100
Publicado: 28 oct 2026 · Última mod.: 28 oct 2026 · CWE-668
0.4%EPSS · 30 días0.4%
2026-10-282026-11-01
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.
- github.comhttps://github.com/google/adk-python/commit/0ae2bffdd2628af6c8643bc4fd40c2f49f0c6bd4
- github.comhttps://github.com/google/adk-python/commit/c27d8688ed9ea619587ad96cbfd641c34dd7340c
- github.comhttps://github.com/google/adk-python/commit/f72f0db58c5c1f4e8b8d4f04b8c592c9e49cbe9e
- github.comhttps://github.com/google/adk-python/issues/5618
- github.comhttps://github.com/google/adk-python/pull/5619
- github.comhttps://github.com/google/adk-python/releases/tag/v1.39.1
- github.comhttps://github.com/google/adk-python/releases/tag/v2.7.0
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1203089.9 CRÍ—
——0A Beta9 tenant can attach a volume when deploying a function, endpoint, or task queue. The gateway builds the host path by joining the shared volumes root, the workspace name, and the volume identifier from the stub configuration. Nothing checks that the identifier names a volume that workspace owns. Parent-directory segments in the identifier collapse the joined path to the worker's filesystem root, and the worker bind-mounts that path into the sandbox read-write unless the volume was explicitly marked read-only. A tenant with a workspace token can therefore read and write the worker's files, including other tenants' volumes stored on that machine. Confirmed against gateway 0.1.769 and worker 0.1.745. Fixed in gateway 0.1.776 and worker 0.1.756: volume identifiers and mount paths are validated before a mount is built, including for stubs saved before the check existed, and the gateway rejects a volume that does not exist or is not owned by the workspace.1dCVE-2026-571448.8 ALT10.8%
——3PraisonAI is a multi-agent teams system. From version 4.5.110 to before version 4.6.61, praisonai.sandbox.SandlockSandbox is documented and implemented as the kernel-enforced sandbox backend for untrusted code. Its SandboxConfig.native() path lets callers configure allowed filesystem paths and network=False. On systems where the optional sandlock module imports but reports that Landlock is unavailable, SandlockSandbox.execute() and run_command() do not fail closed. They silently fall back to SubprocessSandbox(self.config). That fallback keeps the same high-level native policy object but does not enforce the native filesystem or network boundary during code execution. A sandboxed payload can read files outside the configured allowed path and open network connections despite network=False. This issue has been patched in version 4.6.61.5dCVE-2026-1129366.1 MED14.1%
——4filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.12dCVE-2025-101498.2 ALT7.4%
——2The SCIM endpoint does not sufficiently validate authorization for federated users when performing operations against the local user store. This occurs when a local and a federated user share the same username, allowing a federated user to perform actions intended for a local user, including arbitrary operations.
A malicious actor authenticated as a federated user may perform arbitrary operations on local user accounts via the SCIM 2.0 or SCIM 1.1 endpoints when local and federated users share the same username. This could lead to user account takeover. Deployments that do not support user self-registration are considered medium severity.13dCVE-2026-1063544.3 MED12.5%
——4Improper resource exposure in Extensions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium)19dCVE-2026-1040737.6 ALT30.4%
——9NetBox versions 2.9.5 before 4.7.0 contain a server-side template injection vulnerability that allows a low-privileged user with the "Can add custom links" permission to steal session cookies and API tokens of other users by exposing the raw Django HttpRequest object to the Jinja2 template context. Attackers can craft a custom link template embedding request.COOKIES['sessionid'] or a user's API token into an img src URL, which bypasses the clean_html sanitizer and auto-exfiltrates the victim's credentials to an attacker-controlled host when a privileged user views the object, enabling full account takeover.26d