CVE Watch4 de nov. de 2026

CVE-2025-10149

The SCIM endpoint does not sufficiently validate authorization for federated users when performing operations against the local user store.

CVSS

8.2

Alta

EPSS

0.2%

KEV

—

Exploit Today

0-100

Publicado: 19 de out. de 2026 · Última mod.: 4 de nov. de 2026 · CWE-281 · CWE-668

EPSS · 30d

0.2%EPSS · 30 dias0.2%

2026-10-202026-11-05

Descrição técnica

The 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.

Referências oficiais

security.docs.wso2.comhttps://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4438/

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-48183—

2.8%

——1Improper permission handling during buffer operations allows untrusted applications to create memory mappings with inappropriate permissions1d CVE-2026-102280—

1.2%

——0Sandboxie-Plus is an open source sandbox-based isolation software for Windows. Prior to 1.18.6, a process inside a sandbox could send MSGID_FILE_SET_ATTRIBUTES or MSGID_FILE_SET_SHORT_NAME to SbieSvc and cause the SYSTEM service to open and modify an existing file outside the sandbox. The direct primitive changes file attributes, timestamps, writeability, or 8.3 short names; a short-name redirection can additionally contribute to SYSTEM code execution when a privileged process resolves an attacker-controlled short-name path in a location SbieSvc can open. This vulnerability is fixed in 1.18.6.17h CVE-2026-121175—

8.0%

——2Improper resource exposure in ORB in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass site isolation via a crafted HTML page. (Chromium security severity: Low)3d CVE-2026-1211688.8 ALT

31.0%

——9Improper resource exposure in DevTools in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low)1d CVE-2026-1203089.9 CRÍ

44.8%

——13A 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.4d CVE-2026-115522—

31.9%

——10Exposure 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.21h