LoopX: any website can read serve-status control-plane state

1. Upgrade LoopX: python3 -m pip install --upgrade loopx. Any release from 0.4.5 on has the fix, and every PyPI release (0.4.8 and later) includes it.
2. Restart any running loopx serve-status process after the upgrade, including the one the macOS dashboard LaunchAgent keeps running after every login, so the new code is loaded.
3. Until you upgrade, stop loopx serve-status when you are not using the dashboard.
4. In Chrome 142 or later, keep the Local Network Access prompt on and deny it for sites you do not expect to talk to local services.

loopx serve-status runs a local HTTP server that feeds the LoopX dashboard. It has no authentication and listens on fixed default ports: 8765 for a project and 8766 for the global view that the macOS dashboard LaunchAgent starts. Before 0.4.5 every response carried Access-Control-Allow-Origin: *. That told the browser any website may read the replies, so a page the user visited could read LoopX state and the Markdown files inside registered goal repos with a plain request and no user interaction.

LoopX (loopx) before 0.4.5, when loopx serve-status is running. The repository was later renamed from huangruiteng/loopx to loopx-project/loopx. Fixed in 0.4.5 (2026-08-12). LoopX is published on PyPI from 0.4.8 on, and all of those releases include the fix, so only installs from the GitHub source or releases before 0.4.5 are affected.

While serve-status ran, a web page on any origin could read:

• GET /status.json: the full status view, with goal ids, run history and local absolute paths (the registry and runtime root). With --global-registry, which is how the macOS dashboard LaunchAgent runs it, this covers every project registered on the machine.
• GET /review-material: the content of any .md or .markdown file under a goal's repo root, state directory or runtime directory. In practice that means private design notes, handoff docs and evidence write-ups.
• GET /: endpoint discovery, including which write APIs are turned on.
• POST /control-plane/configure-goal/dry-run: this route had no Origin check and the preflight reply allowed Content-Type, so a page could read the before and after control-plane settings for a goal. It does not write anything.

LoopX's own docs/public-private-boundary.md lists local absolute paths, task ids, raw logs and active goal state as material that must stay private. The fixed, well-known ports mean a page needs no discovery step.

Not affected. The write routes (POST /reward/append and POST /control-plane/configure-goal/apply) already checked Origin and refused foreign sites, so there was no cross-site write. /review-material blocked path traversal, paths outside the goal roots and non-Markdown files. This is a read of status data and Markdown under registered goals, not arbitrary file read and not code execution.

Browser mitigation. Chrome 142 and later ask the user for Local Network Access permission before a public web page can reach a local address. If the user denies it, the read is blocked in Chrome. Other browsers were not verified.

Permalinks at 2e6c8e6, the commit just before the fix.

• Wildcard CORS in _send_json, the single response path for every route: loopx/status_server.py#L143-L153
• Same wildcard in do_OPTIONS, which also allows Content-Type: loopx/status_server.py#L155-L160
• Read routes (/healthz, /review-material, /, /status.json): loopx/status_server.py#L766-L820
• Markdown read handler: loopx/status_server.py#L596-L636
• Control-plane dry-run with no Origin check: loopx/status_server.py#L520-L535
• Existing is_loopback_origin() check, used only on write routes: loopx/status_server.py#L96-L103
• Default port 8765: loopx/status_server.py#L26
• macOS LaunchAgent defaults to port 8766 and runs serve-status --global-registry: scripts/macos-dashboard-launchagent.sh#L10 and #L115

• #3137 (merged as 838720f) adds cors_response_headers(). It echoes the request Origin back, with Vary: Origin, only when that origin is loopback. Foreign origins and clients that send no Origin get no CORS headers, so browsers block cross-site reads. _send_json and do_OPTIONS both use it, and the write routes keep their existing Origin checks. Released in 0.4.5.
• The dashboard keeps working, because it is served from a loopback origin.
• The fix is still in place at main today: loopx/status_server.py#L178-L195.

Look for requests to the status server (port 8765 or 8766 by default) that carry an Origin of a site the user did not open on purpose, especially GET /status.json and GET /review-material. The server only logs requests when verbose mode is on, so a proxy or endpoint tool may be the only record. A working exploit is withheld.

1. 2026-08-07Reported privately via GitHub PVR (GHSA-vx2m-gpq4-8j5q), with a suggested fix.
2. 2026-08-12Maintainer merges #3137, releases 0.4.5 and publishes the advisory.
3. 2026-08-14Maintainer requests a CVE from GitHub.
4. 2026-08-16First LoopX release on PyPI (0.4.8), with the fix.
5. 2026-10-09CVE still not assigned; follow-up sent to GitHub. Public write-up.

Finder: Aaron Elijah Mars of Aeon. Tool: Aeon.

• Fix PR (merged 2026-08-12): loopx-project/loopx#3137
• Fixed release: LoopX 0.4.5
• GitHub advisory: GHSA-vx2m-gpq4-8j5q
• Related advisory published by the maintainer for the same fix: GHSA-p7c9-q3rc-f4f5
• CVE: pending (requested from GitHub)
• Affected repository: loopx-project/loopx