Popular AI Coding Tool Cline Hijackable by Any Website (CVE-2026-59723): Command Execution and API Key Theft — Update to 3.0.30

Cline, the AI tool that helps with programming and has been installed more than 5 million times worldwide, has a serious hijacking vulnerability. It is tracked as CVE-2026-59723, with a severity of CVSS 8.8 (High, out of 10). The scary part is that simply opening a website prepared by an attacker in your browser can let them hijack the Cline running on your own machine.

The flaw is in a communication endpoint that Cline's "dashboard" feature (a control panel launched with cline dashboard) quietly runs inside your computer. Because that endpoint accepts commands without checking which website is talking to it, an unrelated malicious site can operate it. Once hijacked, an attacker can make the AI run arbitrary commands and steal files on your machine, and even the access keys (API keys) for your AI services. According to the vendor's advisory, anyone using the default configuration is exposed as-is.

To make things worse, this is already the second time this year the same class of flaw has hit Cline. In May, an even more severe issue in a different screen feature was disclosed as CVE-2026-44211 (CVSS 9.7). The fix for the dashboard flaw is Cline 3.0.30, and the May flaw was fixed in 0.1.66. If you use Cline, update to the latest version now. As of publication, there is no entry in the U.S. CISA catalog of vulnerabilities under active attack (KEV) and no report of real-world damage, but proof-of-concept code that reproduces the attack is already public.

What Cline is, and why this hole is dangerous

Cline is an open-source AI coding agent that plugs into the code editor Visual Studio Code. Originally released as "Claude Dev," it has grown into a hugely popular tool with over 61,000 GitHub stars and more than 5 million installs. It connects to more than 30 AI models such as Claude, ChatGPT, and Gemini, and goes well beyond autocomplete: it reads your source code and edits files itself, runs commands in the terminal, and even drives a browser — an "agent"-type tool that carries out development work on your behalf.

Having that much power means Cline sits in a place where it can reach your source code, your terminal, your Git repositories, and even your cloud credentials. That is exactly why hijacking it does so much damage. This vulnerability lived in a small server that Cline runs purely inside your computer for the sake of a convenience feature.

Cline has screen features such as a "dashboard" that shows your work status at a glance and a "Kanban" board that manages tasks as cards. When you run these, Cline opens a communication channel on 127.0.0.1 (the address that points to your own machine and is only visible from inside your computer) to link the browser view with the back end — a WebSocket, the mechanism that lets a browser and a server keep talking to each other in both directions. This was supposed to be safe because it is "communication only inside my own machine." But there is a blind spot: the browser's safety guard does not apply to WebSockets.

Ordinary communication between web pages is governed by the same-origin policy (CORS), which prevents one site from arbitrarily reading the contents of another. WebSockets, however, are outside that restriction, so any site on the internet can connect to a WebSocket running inside your computer. That means unless the side receiving the connection (Cline) checks "which site did this connection come from," it will accept connections from malicious sites as-is. The true nature of this flaw was exactly that: a forgotten check of "who is talking to me."

Who attacks, what they want, and how far the damage reaches

Before the technical details, let's clarify whether this hole is "relevant to you." The danger arises when you leave Cline's screen features (the dashboard or Kanban) running on your machine and then open an unknown site in another tab. Whether you are a target depends on how you use it.

The people who profit from this hole are not pranksters. They are financially motivated attackers and supply-chain attack groups who target developers' machines to steal the source code, cloud credentials, and AI-service API keys stored there. They lure developers to "a page that looks perfectly ordinary" using ads, hijacked sites, or links on social media.

When the developer opens that page, a program embedded in it quietly connects to the Cline WebSocket running inside the machine and registers a new "tool" (an MCP server) into Cline without permission. MCP (Model Context Protocol) is the mechanism for connecting external tools to an AI agent. When an attacker registers a crafted "tool" here, its contents can smuggle in commands (shell commands) that run on the machine. And because the dashboard's default setting auto-approves tool use (autoApproveTools: true), the malicious command that was registered runs as-is without the user's confirmation.

The first to be hit is the developer using Cline. If arbitrary commands run on the machine, that leads to leaked source code and API keys, tampering with the development environment, and using it as a foothold to break into the corporate network. Furthermore, if that developer builds a company's software, stolen information or planted malicious code can propagate through that company's products all the way to end users. In fact, Cline already went through an incident this February in which its own development pipeline was abused to publish an unauthorized version to npm that silently installed another program on developers who updated (a so-called supply-chain attack). Behind "hijacking a developer's machine" hangs every piece of software that person touches.

What actually happened: the technical details

This whole series of problems shares the same root: a WebSocket opened inside the computer did not verify the Origin (which site the connection came from) of the party connecting to it. Two of Cline's features each received a separate CVE number.

CVE-2026-59723: WebSocket hijack of the dashboard (CVSS 8.8)

This is the newer hole caught by our detection this time. The control panel launched with cline dashboard opens an endpoint at ws://127.0.0.1:8787/browser by default. According to the vendor security advisory (GHSA-3cj3-hqcr-g934), the endpoint's authorization check hinged on whether a passphrase (the environment variable ROOM_SECRET) was set. But in the normal local setup, ROOM_SECRET is not set, and in that case the authorization function returns "allowed" unconditionally. On top of that, no Origin check was performed at WebSocket connection time, so connections from external malicious sites passed through entirely.

After connecting, the attacker sends an upsert_mcp_server command to write a malicious MCP server containing shell commands into the settings file cline_mcp_settings.json. As noted, the dashboard session has tool auto-approval enabled, so the written command runs. The report came from the security research team EQSTLab, and it included proof-of-concept code that reproduces the attack with Docker and a simple script. The fix is Cline 3.0.30, which adds authorization and an Origin check so that requests no longer pass through when ROOM_SECRET is unset.

CVE-2026-44211: the same-shaped hole in the Kanban server (CVSS 9.7)

This is the more severe earlier case that security firm Oasis Security disclosed in May. The local server for the Kanban feature, which manages tasks as cards, opened a WebSocket at 127.0.0.1:3484 with no Origin check and no passphrase authentication at all. As the researchers put it, "any JavaScript running in the developer's browser can reach it." When a malicious site connects, the Kanban server sends back a complete snapshot of the working workspace (file paths, task details, Git branch names, and the AI chat history) as-is.

The attacker could also inject a prompt (an instruction) into the AI agent and simulate a keypress so the AI accepts it as a legitimate instruction. This runs an arbitrary shell command in the terminal, reaching remote code execution (RCE). Terminating active tasks to disrupt work is possible too. The reason its CVSS of 9.7 is the highest of the three here is that there is no authentication at all, and the damage runs in a straight line from data leakage to code execution. The fix is version 0.1.66 of the Kanban package.

The two CVEs affect different components and different ports, but the shape of the failure — "opening a local WebSocket for a convenience feature and neglecting to verify the source of the connection" — is exactly the same. Locally running services tend to be trusted with "it's only inside my own machine anyway," but these two cases in quick succession drove home the fact that they are reachable from across the internet by way of the browser.

Timeline from discovery to fix

← Swipe to move

Even though the May Kanban incident had already pointed out the same kind of hole, an almost identical one turned up in the dashboard in July. It suggests the question of verifying the source of locally opened WebSockets had not been swept across the whole product. The dashboard hole, CVE-2026-59723, was added to NVD on July 8, 2026.

What to do right now

The basic response is to update Cline to the latest version. Depending on how you use it, there is more to do.

• Everyone using Cline: update to Cline 3.0.30 or later. Even if you think you don't use the screen features, a local server can start up as a result of extension actions, so staying on the latest version is the safe choice.
• If you use the dashboard (cline dashboard): in addition to updating, set the environment variable ROOM_SECRET to enable passphrase protection. It also helps to avoid leaving the dashboard open after you finish working.
• If you use the Kanban feature: update Kanban to 0.1.66 or later. Since it was fixed back in May, the longer you have gone without updating, the more you should pay attention.
• General hygiene: don't run local servers on a network that is reachable from outside, and don't carelessly open sites of unknown origin while doing development work — these basics also reduce the damage.

Cline is distributed via npm and the VS Code extension marketplace, so even if you embed it into CI/CD or a shared team development environment, don't forget to check the version and update. Oasis Security also recommends auditing other AI development tools you run locally for the same kind of missing source-verification.

From an engineer's view: the recurring "local means safe" assumption

The root of this is a single thing: a WebSocket opened locally (127.0.0.1) forgot to include a step that verifies the Origin of the connection. Underlying it is the assumption that "a service running only inside my own machine can't be touched from outside," but that is not true. While browsers restrict HTTP requests from web pages via CORS, they do not apply that restriction to WebSocket connections. So the moment a developer opens a malicious page, that page's JavaScript can freely connect to ws://127.0.0.1:.... The responsibility for defense is on the server side, and the standard practice is to inspect the Origin header on connection and reject connections from anything other than the intended view. Requiring passphrase (token) authentication is another effective measure.

This pattern keeps recurring in development tools that suddenly came into wide use in the AI era. The SSRF in Repomix, the popular tool that hands code to AI, which turned its public server into a proxy, the case where the AI tool Langflow was attacked right after disclosure, the vulnerability in Amazon's AI development tool Kiro, the flaw in the command-line tool for the data platform Snowflake, and the vulnerability in the developer tool mise — the pattern of accepting external input or connections while prioritizing convenience, then finding a hole afterward, keeps going. Precisely because AI agents sit where they can reach "the things you least want stolen" — code, terminals, and credentials — their safety will be questioned more and more, including from the standpoint of the open-source supply chain. Vulnerabilities observed to be actively attacked are added to CISA's KEV (the catalog of vulnerabilities under active attack) on an ongoing basis, so it is reassuring to check that too.

Frequently asked questions

Summary

Cline, an AI coding tool used by more than 5 million people, has a vulnerability (CVE-2026-59723, CVSS 8.8) in which simply opening a malicious website can hijack the AI on your machine, leading to command execution and the theft of API keys and source code. The cause was that a WebSocket opened inside the computer did not verify the source of the connection. And this was the second time Cline made the same kind of mistake, following the Kanban hole disclosed in May (CVE-2026-44211, CVSS 9.7). The fix is simple: update Cline to the latest version (3.0.30 or later, and Kanban 0.1.66 or later), and if you use the dashboard, set a passphrase (ROOM_SECRET). How dangerous the "local means safe" assumption is in the age of AI agents — because you entrust such a powerful partner with so much, this is a case that makes you check that partner's defenses.

References

• ›NVD — CVE-2026-59723 (dashboard)
• ›GitHub Security Advisory — GHSA-3cj3-hqcr-g934
• ›NVD — CVE-2026-44211 (Kanban)
• ›Oasis Security — Cline Kanban WebSocket Hijack
• ›GitLab Advisory — CVE-2026-44211 (fixed in 0.1.66)
• ›Infosecurity Magazine — Cline Kanban Flaw
• ›Cline Releases (3.0.30)
• ›Cline official repository