LoopX EUVD-2026-103186

Requires that the operator is actively running loopx serve-status (the status_server.py HTTP server) on a reachable loopback port AND, in a browser sharing that session, visits attacker-controlled web content that scripts cross-origin requests to that port. Exploitation is limited to the four unauthenticated read routes (GET /status.json, GET /review-material, GET /, POST /control-plane/configure-goal/dry-run) and is read-only - no cross-origin writes or arbitrary-file access are possible. Limiting factors: the attacker must know or guess the loopback port (described as predictable), the operator must perform the user-interaction step of visiting the malicious page (UI:P), and affected versions are 0.0.1 through pre-0.4.5.

This is a genuine but bounded-impact issue best treated as medium priority, not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N) correctly captures a read-only cross-origin information-disclosure flaw: no privileges needed, low attack complexity, but exploitation DEPENDS on passive user interaction (UI:P) - an operator must visit attacker-controlled web content while loopx serve-status is running. The 7.1 score is driven entirely by VC:H (confidentiality); VI/VA are N, consistent with the advisory's explicit statement that the affected routes provide no cross-origin writes or arbitrary-file access. No EPSS score, KEV listing, or POC was provided in the input, so there is no evidence of active exploitation or published exploit code - the real-world threat is opportunistic and requires both a running local status server on a predictable loopback port and successful social engineering of the operator's browser. The signals are internally consistent (network-reachable via browser, gated by user interaction and loopback reachability), so there are no contradictions to flag; the main caveat is that EPSS/KEV/POC data is simply absent rather than confirmed-negative.

An operator runs loopx serve-status on a predictable loopback port and, in the same browser session, visits a malicious web page. That page's JavaScript issues cross-origin requests to the local server (e.g. GET /status.json or GET /review-material?goal_id=...&path=...); because the server returns Access-Control-Allow-Origin: * for unauthenticated responses, the browser allows the attacker's script to read the responses and exfiltrate control-plane state, goal/run metadata, local absolute paths, and private Markdown files below registered goal roots. No public exploit was identified in the provided data, and the attack reads data only - it cannot write configuration or fetch arbitrary files.