Cline — two separate cross-origin WebSocket hijack → RCE CVEs across its VS Code extension and CLI Hub (CVE-2026-44211, CVE-2026-59723)

View raw markdownEdit on GitHub ↗

TL;DR

CVE-2026-44211 (CVSS 9.7) — Cline (the popular VS Code AI coding agent) starts a WebSocket server on port 3484 with no authentication and no origin validation. Any webpage a developer visits can connect to it and execute arbitrary shell commands on their machine. This is a textbook "localhost is not a security boundary" 1-click RCE.

Update 2026-08-03: a second, distinct instance of the identical root cause was found in a different Cline component: CVE-2026-59723 (CVSS 8.8), disclosed 2026-07-08/09, affects the Cline CLI's "Hub" dashboard server (not the VS Code extension's Kanban server above) — its /browser WebSocket endpoint skips Origin validation and, when ROOM_SECRET is unset (the default for local binds), treats any connecting page as authorized. Fixed in Cline CLI 3.0.30.

What happened

Cline versions ≤ 2.13.0 launch a local WebSocket server (the Kanban board server) on port 3484 when the VS Code extension activates. This server: - Binds to localhost - Accepts any WebSocket connection without authentication - Does not check the Origin header of incoming requests

Browsers do not restrict cross-origin WebSocket connections to localhost, so any JavaScript on any webpage the developer visits can silently establish a connection and send commands to the Cline server — which has full access to the developer's file system, shell, and all VS Code workspace permissions.

The vulnerability was published on 2026-06-01 with a CVSS 4.0 score of 9.7. No public PoC URL at time of writing, but the exploit is trivially constructible from the disclosure.

Same attack class as: - OpenClaw CVE-2026-25253 — WebSocket gateway token steal via URL parameter - OpenCode CVE-2026-22812 — POST /session/{id}/shell with CORS * - Marimo CVE-2026-39987 — unauth /terminal/ws

The root cause is identical across all four: a developer-facing tool assumes that "local port = safe" but the browser is the network attacker — any tab the developer opens is LAN-adjacent to every localhost port.

CVE-2026-59723 — the same bug recurring in a second, separate Cline component

GitHub Security Advisory GHSA-3cj3-hqcr-g934 (disclosed 2026-07-08/09) describes an almost identical flaw in an entirely different part of the Cline product: the Cline CLI's "Hub" dashboard server exposes a WebSocket endpoint at /browser on 127.0.0.1, intended only for the local dashboard UI to talk to the desktop agent. The server calls isAuthorizedBrowserRequest() to gate incoming frames, but never validates the Origin header on the WebSocket handshake itself — and when ROOM_SECRET is unset (the default for a local bind), that authorization check falls back to implicitly trusting the connection. Since browsers permit cross-origin WebSocket connections by default, any website a developer visits while Cline Hub is running can open the socket and send desktopCommand frames that read workspace state, rewrite MCP server configuration, change AI provider settings, and — once a provider/model is configured — execute arbitrary commands on the developer's machine. CVSS 8.8. Affects Cline CLI < 3.0.30; fixed in 3.0.30.

This is the Cline CLI/Hub analogue of the VS Code extension's Kanban-server bug above: same missing-Origin-validation root cause, same "browser is the network attacker" exploitation path, different code path and different fixed version — track both independently when auditing which Cline surfaces you run.

Am I affected?

# Check your installed Cline VS Code extension version
code --list-extensions --show-versions | grep saoudrizwan.claude-dev

# Or in VS Code: Extensions panel → Cline → version shown
# If version is < 2.13.0, you are affected while VS Code is open (CVE-2026-44211).

# Separately, check your Cline CLI version if you use Cline Hub
cline --version
# If < 3.0.30, you are affected while Cline Hub is running (CVE-2026-59723).

You are actively exposed while the relevant Cline component is running — the extension's Kanban server while VS Code is open, or the CLI's Hub dashboard while it's running. Any browser tab you visited during that window is a potential attack vector for either bug.

If you are affected

  1. Upgrade both components: the Cline VS Code extension to the release that patches CVE-2026-44211, and the Cline CLI to ≥ 3.0.30 for CVE-2026-59723.
  2. Rotate all credentials accessible from your VS Code workspace and machine if you had a vulnerable version installed with any browser activity.
  3. Audit shell history for unexpected commands: history | tail -100
  4. See playbooks/auditing-a-vibe-coded-repo.md.

Prevention

  • Keep all VS Code AI agent extensions current — most localhost WebSocket vulnerabilities are patched silently via extension auto-updates.
  • Disable silent auto-update of extensions in VS Code (Extensions → ⚙ gear → "Disable Auto Updating Extensions") and review changelogs before updating.
  • Use a browser profile or container separate from your development environment for untrusted web browsing.
  • For any AI agent extension, verify it implements:
  • Origin header validation on WebSocket handshake
  • Per-session authentication token

Sources