A newly disclosed vulnerability in Cline’s dashboard server exposes developers to a stealthy attack: simply browsing to a malicious website while running the cline dashboard command could let that site inject arbitrary code into your local development environment no login, no malware download, no obvious red flags.
Tracked as CVE-2026-59723 and cataloged under GHSA-3cj3-hqcr-g934, the flaw affects @cline/cline-hub versions up to and including 3.0.24.
Security researcher TheRealSpencer published the advisory two weeks ago, with credit also extended to EQSTLab and useworld. The issue carries a CVSS score of 9.6 (High severity) and remains unpatched at the time of writing.
Critical Cline Hub Flaw
Cline Hub’s dashboard, launched via a one-command CLI (cline dashboard), spins up a local WebSocket server on 127.0.0.1:8787 to let a browser tab communicate with the developer’s AI coding sessions. That /browser endpoint is the problem.
The root cause is classic CWE-346 (Origin Validation Error). Browsers automatically attach an Origin header to WebSocket handshake requests, but unlike fetch() or XHR calls, they don’t enforce the Same-Origin Policy on WebSockets that job falls entirely to the server. Cline Hub’s server never checks it.
Worse, the authorization function isAuthorizedBrowserRequest() in server.ts short-circuits entirely when no ROOM_SECRET is configured:
function isAuthorizedBrowserRequest(url: URL): boolean {
if (!roomSecret) return true;
return url.searchParams.get("roomSecret") === roomSecret;
}
Since ROOM_SECRET is unset by default for local binds, this returns true for literally any connection request, cross-origin or not.
Once an attacker-controlled page opens the WebSocket, it can send desktopCommand frames to read session state, mutate settings, or write new MCP (Model Context Protocol) server entries via upsert_mcp_server.
Researchers confirmed this dynamically: a malicious stdio MCP entry was injected into the victim’s cline_mcp_settings.json file with the server responding ok: true.
That injected entry can specify an arbitrary shell command. The next time Cline activates that MCP server, the command executes under the victim’s own user account, achieving persistent remote code execution.
Compounding the risk, dashboard sessions default to autoApprove: true for all tools. If the victim has an AI provider configured, an attacker can also send a send frame instructing the agent to run shell commands directly, skipping any confirmation prompt entirely.
- No authentication needed – the exploit requires zero credentials or prior access.
- One-page visit triggers it – victims don’t need to click anything beyond loading a tab.
- Persistent compromise – injected MCP entries survive across sessions until manually removed.
- Credential exposure – API keys and provider configs accessible via the dashboard become attacker-visible.
- Supply chain risk – injected MCP servers or agent-driven commands can pivot into connected repositories or CI pipelines.
Mitigation
Since no patch exists yet, security teams should treat this as an active-risk configuration issue:
- Always set a strong, unique
ROOM_SECRETenvironment variable before runningcline dashboard, even on localhost. - Avoid running the dashboard while browsing untrusted sites in the same browser session.
- Disable
autoApprovefor dashboard-created sessions where possible. - Monitor
cline_mcp_settings.jsonfor unexpected entries. - Restrict dashboard binding to trusted network interfaces only, and consider adding firewall rules to block unsolicited local WebSocket traffic.
Given the ease of exploitation and the RCE potential, organizations using Cline in developer workflows should flag this advisory for immediate internal review until an official fix lands.