What happened
MoLing is an MCP server package, github.com/gojue/moling, whose advisory describes a vulnerability in its Server-Sent Events mode. The affected versions are 0.4.0 and earlier; version 0.5.0 is the patched release. The issue is tracked as CVE-2026-62863 and GitHub advisory GHSA-qpgh-hp5g-4vwp. The advisory assigns it a critical CVSS 3.1 base score of 9.6.
The vulnerable configuration is SSE mode, started with the -l flag. In that mode, MoLing exposed /sse and /message HTTP endpoints without authentication. At the same time, its underlying mcp-go dependency added Access-Control-Allow-Origin: * to the /sse response. The two conditions mattered together: an unauthenticated local endpoint was made readable by JavaScript from any web origin.
The advisory’s attack sequence is browser-mediated. A victim runs MoLing on 127.0.0.1:6789 and visits a malicious page. That page opens an EventSource connection to http://127.0.0.1:6789/sse. Normally, the browser same-origin policy would stop the page from reading a response from localhost. The wildcard CORS header instead permits the cross-origin read. The page can read the endpoint event, extract the session ID, then use that session ID in requests to /message.
That produces more than an information leak. The advisory says an attacker can send arbitrary MCP tool calls to the local server. The practical effect depends on the tools configured behind that server, but may include local file reads or writes, command execution, or other actions available to the MCP tool set. The advisory explicitly notes that binding to loopback does not stop this particular path: the victim’s own browser makes the connection.
The 0.5.0 fix has several layers. MoLing now removes the wildcard CORS header injected by mcp-go while preserving SSE streaming. It adds middleware requiring a bearer token on every request, accepted through an Authorization: Bearer <token> header or a token query parameter. When a listening address is configured without a supplied token, NewMoLingServer generates a random 32-hex-character token from 16 random bytes and prints it, with a ready-to-use URL, only to standard output rather than log files. The new middleware sequence also requires application/json for POST requests, so cross-origin POSTs trigger a CORS preflight. The token can be configured with --token or -t.
For users unable to upgrade immediately, the advisory recommends not using SSE mode where the machine may encounter untrusted web content, restricting access to the listening port with a firewall or network policy, and avoiding untrusted websites while MoLing runs in SSE mode. Upgrading to 0.5.0 is the direct remediation for affected installations.
What the archive adds
This is a new fact on a known security theme. The LiteLLM Enterprise proxy flaw likewise involved unauthenticated access exposing a sensitive control surface, though its affected component and attack path were different. The Agno 3.1.9 MCP update is relevant because it added browser-origin access to an MCP server, making transport and origin controls a practical design concern rather than a protocol detail.
Trend signal
This strongly supports Agent security moves to runtime boundaries. The failure was not a model following an unsafe instruction. It was an HTTP runtime boundary: a browser-readable event stream, a reusable session identifier, and endpoints that accepted requests without credentials. The patch is correspondingly operational—headers, authentication, token generation, and request validation.
Why it matters
Teams increasingly run MCP servers close to developer workstations, local repositories, browsers, and credentials. That makes “localhost” an incomplete security claim. A hostile page does not need direct network reachability to a local service if the browser can be induced to connect and can read the response under permissive CORS.
The actionable distinction is between a tool server that merely listens on loopback and one that authenticates every operation, limits allowed origins, and treats browser clients as potentially hostile. SSE deserves the same review as a conventional API: inspect whether connection metadata exposes credentials or session handles, whether CORS is inherited from a dependency, and whether a captured identifier authorizes subsequent tool calls. Version upgrades matter here because the patched release changes the transport’s default security posture rather than only correcting documentation.
What happens next
- More MCP maintainers will audit local HTTP and SSE transports for wildcard CORS plus missing request authentication. (3 months, 70%). Watch for: releases adding origin controls or per-request tokens.
- Browser-mediated localhost attacks will become a standard part of MCP deployment reviews. (6 months, 65%). Watch for: deployment guidance that treats a browser tab as an untrusted network client.
Limits and uncertainty
The advisory establishes the vulnerable configuration, its proof-of-concept flow, and the changes in 0.5.0. It does not establish that the flaw was exploited in the wild, how many MoLing installations used SSE mode, or which configured tool sets were exposed in real deployments. The possible outcomes—file access, command execution, and other actions—depend on each server’s available MCP tools and permissions. The advisory also does not demonstrate that other MCP servers share this exact implementation flaw; the broader lesson is a review hypothesis, not evidence that every SSE-based server is vulnerable.
Skill to build now
Inventory every local MCP endpoint that uses HTTP, SSE, or a browser-accessible transport. For each one, test from a separate web origin whether an event stream is readable, identify whether session values can be replayed, and verify that every tool-call endpoint requires an explicit credential. Then pin patched versions and make CORS policy an intentional configuration rather than a dependency default.
Reader takeaway
CVE-2026-62863 is a reminder that a local MCP server can be exposed through the browser even when it binds only to 127.0.0.1. If an SSE stream is readable cross-origin and its session identifier authorizes requests, a malicious webpage can turn a local tool server into its own client. Upgrade affected MoLing deployments to 0.5.0 and audit the same boundary elsewhere.
Open question
How many MCP servers using browser-reachable HTTP transports still combine permissive CORS with session identifiers that can authorize tool calls without a separate per-request credential?