ADK for Java EUVD-2026-108585

Exploitation requires (1) the ADK Web development server to be actively running - typically on a developer's localhost - and (2) the developer to visit an attacker-controlled web page in a browser on the same machine while the server runs (this is the UI:P passive-interaction requirement). No authentication and no non-default configuration are needed: in affected versions the /run_live WebSocket accepts connections from any origin by default (hardcoded setAllowedOrigins("*") in 0.1.0-1.5.0; defaulting to * via adk.web.cors.origins in 1.6.0-1.12.0) and, since 0.4.0, the REST API returns Access-Control-Allow-Origin: *. Binding to localhost does NOT limit exploitation because the malicious requests originate from the developer's own browser. Limiting factors that reduce real-world risk: the vulnerable component is a developer-facing dev server rather than a production service, the server must be running at the time of the visit, and the developer must be lured into opening the malicious page. In 1.6.0-1.12.0 the exposure can be mitigated without upgrading by setting adk.web.cors.origins to an explicit trusted allowlist (e.g. http://localhost:8000); version 1.13.0 is the complete fix.

This is a genuine but context-limited risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:L, 7.2 High) describes a network-reachable, low-complexity, unauthenticated flaw whose only gating factor is passive user interaction (UI:P) - a developer must visit a malicious page while the local ADK Web dev server is running. The description confirms the mechanism rather than leaving it to inference: default CORS/WebSocket origin handling is permissive (setAllowedOrigins("*") hardcoded in 0.1.0-1.5.0, defaulting to * in 1.6.0-1.12.0, and Access-Control-Allow-Origin: * on the REST API since 0.4.0), and the server has no authentication, so localhost binding does not protect it because requests originate from the developer's own browser. Exploitation signals are modest: there is no CISA KEV listing and no EPSS score in the input, and the PoC is a reference only, not verified working exploit code - so this is 'no confirmed active exploitation' territory, consistent with the vendor's own 'this_week' (not act_now/emergency) priority label. The real-world ceiling is set by the product: this is a developer-only dev server, not a production-facing service, which bounds blast radius even though the technical impact (read/create/delete sessions and artifacts, trigger registered agent tools) is serious on an affected workstation. Net: a real priority to patch in development environments, but not a widespread internet-facing emergency.

A developer starts the ADK Web dev server locally (e.g. on localhost:8000) and, while it is running, visits an attacker-controlled web page. That page's JavaScript opens a cross-origin connection to the /run_live WebSocket and the REST API - both of which accept any origin by default - and sends messages to the local agent, streams its responses, and lists, reads, creates, or deletes the agent's sessions and artifacts. A public PoC reference exists (google/adk-java issue #1257); it is not verified as working exploit code.