Loopback Is Not a Boundary: MoLing's SSE Mode Leaked MCP Session IDs to Any Web Page
NVD published CVE-2026-62863 on 30 October 2026 with a CVSS 3.1 score of 9.6 (AV:N/AC:L/PR:N/UI:R/S:C) against gojue/moling, a computer-use and browser-use MCP server. Before 0.5.0, running MoLing in Server-Sent Events mode with the -l flag left the /sse and /message HTTP endpoints with no authentication — and the underlying mcp-go dependency stamped Access-Control-Allow-Origin: * on the SSE responses. Any web page, from any origin, could open a cross-origin EventSource to the local listener, read the stream, and extract the sessionId from the endpoint event. With that token, the attacker's page could send arbitrary MCP tool calls to /message: reading or writing local files, executing commands, or whatever else the configured tools permitted. Binding only to loopback did not help, because the victim's own browser carried the attack across the boundary.
The attack scenario in the advisory is disarmingly short: the victim runs moling -l 127.0.0.1:6789, visits a malicious page, and that page's script opens an EventSource to http://127.0.0.1:6789/sse. Same-origin policy would normally block the read, but the wildcard CORS header explicitly lifts the restriction, so the page harvests the sessionId and starts issuing tool calls. No network position, no credentials, no MCP expertise required — one click on one tab compromises the agent running on the machine. The fix release v0.5.0 closes it (upstream commit ae07f70, PR #48, advisory GHSA-qpgh-hp5g-4vwp), and the NVD record carries the fix references.
The dependency did half the damage
Note the two-layer structure: MoLing's missing authentication is the primary defect, but the wildcard CORS header came from mcp-go, a shared dependency. Either flaw alone is serious; together they convert a local UX convenience (SSE mode for browser clients) into remote code execution mediated by the victim's browser. This is the same composition pattern behind the week's other MCP failures — a repo name reaching a shell in ai-sdlc, an unauthenticated sandbox listener in OpenHands — and the reason the MCP reference servers' eight-fix release matters: the ecosystem keeps shipping transport without authentication and trusting the network location to compensate. Loopback is an address, not an authorization decision, and CORS wildcards on stateful endpoints are remote-access features wearing local-access clothes.
What to do
- Upgrade to MoLing 0.5.0 now. Anything earlier in SSE mode exposes its session to every web page the operator visits. If you ran SSE mode on an untrusted-browsing machine, rotate any credentials the configured tools could reach.
- Never ship ACAO: * on stateful or session-bearing endpoints. Wildcard CORS on SSE/streaming transports is a cross-origin read primitive. Pin allowed origins, and require per-connection tokens even on loopback listeners.
- Treat sessionIds as credentials. Anything that discloses them in a readable stream needs the same authentication as the privileged channel itself — the
/sseendpoint was effectively the keys to/message. - Pin and audit framework defaults. When a dependency like
mcp-gosets security-relevant headers, that default becomes your posture. Test what your MCP server actually emits on the wire, not what the docs imply.
Sources:
- NVD — CVE-2026-62863 (published 30 October 2026; CVSS 3.1 9.6, CWE-942, fix commit ae07f70 and PR #48 references; read first-hand)
- gojue/moling — GHSA-qpgh-hp5g-4vwp (SSE mode unauthenticated endpoint with CORS wildcard leaking sessionId; attack scenario and PoC sketch; read first-hand)
- gojue/moling — v0.5.0 (fix release; cited via NVD references)