Cross-origin WebSocket hijack in Cline exposes agent trust gaps

At a glance

What this is: A CVSS 9.7 cross-origin WebSocket flaw in Cline’s local kanban server let arbitrary websites read workspace data, inject terminal commands, and terminate tasks.

Why it matters: IAM and security teams should treat local agent UIs as identity-sensitive attack surfaces because browser trust boundaries now reach into developer tooling, terminal access, and delegated AI execution.

👉 Read Oasis Security's analysis of the Cline cross-origin WebSocket hijack

Context

Cross-origin WebSocket hijack in Cline is an identity and runtime trust problem, not just a browser bug. The issue sits at the point where a developer’s browser, local listener, and AI agent share a machine and a trust boundary that existing IAM controls do not normally model.

Cline’s local kanban server was designed to let a browser UI talk to a local agent session, but it accepted connections from any origin without authentication. That means a website could become an untrusted caller into a tool that already had access to source code, terminals, repositories, and cloud credentials. This is a classic case of delegated access being reachable from outside the intended control plane.

For teams running AI coding tools, the governance question is whether the local service is part of the identity perimeter or merely an application detail. The article shows that once a local listener can accept arbitrary web traffic, browser activity becomes a path into developer workspace identity and agent execution.

Key questions

Q: What breaks when a local AI agent service accepts browser connections from any website?

A: The trust boundary collapses because the browser becomes an untrusted transport into a privileged local control plane. That can expose workspace data, enable command injection, and let a malicious page interfere with active agent tasks. Security teams should treat localhost listeners as governed access points, not harmless developer conveniences.

Q: Why do AI coding agents create a bigger access risk than ordinary developer tools?

A: They often combine source code access, terminal execution, repository context, and cloud credentials in one runtime. If the interface that manages the agent is reachable from an untrusted browser origin, an attacker can turn observation into execution. The risk is not the agent label itself, but the privileges attached to it.

Q: What do security teams get wrong about WebSocket-based local services?

A: They assume browser protections that apply to normal web requests also protect persistent local WebSocket channels. In practice, a localhost listener can be reachable from arbitrary websites unless it enforces its own origin and authentication controls. That is why local management channels must be reviewed like other privileged interfaces.

Q: How should organisations govern browser-accessible AI development tools?

A: They should classify them as identity-sensitive runtime services and apply the same scrutiny used for privileged admin tools. That means validating who can connect, what each channel can do, and whether command-bearing paths are isolated from read-only telemetry. If the browser can reach it, the interface is part of the security boundary.

Technical breakdown

Cross-origin WebSocket access to localhost

WebSockets are persistent network channels that can bypass the expectations many teams have from same-origin browser protections. In this case, the local kanban server exposed a WebSocket listener on localhost and did not verify origin, authenticate the client, or confirm that the caller was the intended UI. Because browser security treats WebSocket connections differently from ordinary HTTP requests, any page the developer loads can attempt a connection. The result is not remote code execution in the classic sense, but an untrusted browser session reaching a privileged local control plane.

Practical implication: inventory every local listener in AI developer tooling and require origin validation plus authentication before any browser can talk to it.

Workspace snapshot streaming and command injection

Once the connection was accepted, the server streamed high-value context such as filesystem paths, task titles, branch names, and agent chat history. It also exposed a terminal input channel that could receive attacker-chosen commands, which the agent executed as though they were legitimate instructions. The security boundary failed because the server treated the browser client as trusted simply by virtue of being local, while the browser itself could be controlled by any website. That turns a convenience channel into an execution path.

Practical implication: separate read-only workspace telemetry from any command-bearing channel and require explicit trust decisions before terminal input is accepted.

Task termination as a control-plane denial of service

The same local service also allowed connected clients to terminate active agent tasks. That creates a control-plane denial-of-service condition, because availability of the developer workflow depends on the integrity of the local management channel. In practical terms, the issue is broader than data theft or shell access. An attacker with access to the listener can interfere with task execution, stop work in progress, and undermine confidence in the agent orchestration layer. This is a governance failure in the interface that manages the agent, not just in the agent itself.

Practical implication: protect agent task controls with the same identity checks and session boundaries you would apply to privileged admin operations.

Threat narrative

Attacker objective: The attacker aims to exfiltrate developer workspace context and gain indirect control over the AI agent’s terminal and task execution.

1. Entry occurred when a developer visited a malicious or compromised website while Cline’s local kanban server was running, allowing the page to connect cross-origin to localhost.
2. Credential access and abuse followed when the server disclosed live workspace data and accepted command-bearing WebSocket traffic as if it came from the trusted UI.
3. Impact came through command injection and task termination, giving the attacker shell-level influence over the developer’s agent workflow and the ability to disrupt active work.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Local listener trust is the broken assumption here: the server assumed that because a client was connecting from the developer’s machine, it was therefore trusted. That assumption was designed for a single controlled UI path, not for arbitrary web content reaching localhost. The implication is that browser-originated traffic must be treated as potentially hostile whenever it can reach an agent control channel.

Cross-origin WebSocket hijack is a named governance gap: it combines missing origin checks, missing authentication, and overbroad local exposure into one failure mode. This is not just insecure coding, it is a control-plane design flaw for agentic tooling. The practical conclusion is that local agent interfaces now belong in the identity perimeter, not outside it.

Agent-facing tools inherit the blast radius of the developer’s browser: once the browser can become an attacker-controlled transport, the agent’s access to code, terminals, and cloud credentials is no longer bounded by the intended UI. That changes how risk must be modelled for AI coding assistants and similar NHI-adjacent tools. Practitioners should treat any browser-reachable agent channel as privileged access.

Purpose-built runtime controls matter because static trust models fail at the edge: the article shows why conventional IAM assumptions break when a local service conflates convenience with authorization. OWASP-NHI and zero-trust-style controls are relevant here because the issue is uncontrolled access to non-human execution surfaces. The implication for teams is to reclassify local agent services as governed assets, not developer utilities.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• For a broader lens on the control gap, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for why long-lived trust assumptions keep failing in machine-access paths.

What this signals

Cross-origin WebSocket hijack: this is a useful shorthand for the class of failures where a local agent UI trusts browser traffic that was never authenticated as the intended operator. As AI development tools spread, governance teams should expect more browser-to-localhost exposure and should map those surfaces into their identity review processes. For a control baseline, NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both reinforce the need to manage runtime access paths, not just model outputs.

The operational signal is not whether the tool is branded as an agent, but whether it can accept privileged actions from a channel that the organisation does not explicitly govern. With 23.7% of organisations sharing secrets through insecure methods such as email or messaging applications, per The 2024 Non-Human Identity Security Report, the broader pattern is familiar: convenience channels become security boundaries by accident.

Teams should now expect endpoint policy, browser controls, and local service hardening to show up in AI developer governance discussions. The more a local tool can see code, sessions, and credentials, the more it should be treated like a managed identity workload rather than a desktop utility. That shift will matter most in environments where autonomous or semi-autonomous coding agents are being introduced without a full asset inventory.

For practitioners

• Inventory every browser-reachable local agent service Identify developer tools that open localhost listeners for AI agent sessions, then verify whether they enforce origin checks, client authentication, and process-level binding restrictions.
• Split telemetry from command channels Keep read-only workspace sync separate from terminal input or task-control channels so an untrusted caller cannot turn observation into execution.
• Require explicit trust for terminal-bearing paths Gate any terminal input or task termination action behind a separate authorization step, even when the caller is on the same host.
• Tighten endpoint controls around localhost exposure Use host firewall rules and endpoint security policies to limit which processes can bind local ports and which browsers can reach them.

Key takeaways

• The breach shows that a local AI agent UI can become a privileged access path if it accepts untrusted browser traffic.
• The evidence is severe: a CVSS 9.7 flaw enabled real-time workspace exfiltration, command injection, and task disruption from ordinary web browsing.
• The control that would have limited the issue was simple but missing, namely authenticated origin-checked access to the local management channel.

Key terms

• Cross-Origin WebSocket Hijack: A cross-origin WebSocket hijack occurs when an untrusted webpage connects to a WebSocket service that was intended only for a trusted local client. In AI development tools, that can expose workspace data or command channels because the server trusts the connection without verifying origin or identity.
• Local Agent Control Plane: The local agent control plane is the set of interfaces that manage an AI coding agent on a developer’s machine, including task status, telemetry, and terminal input. If that plane accepts arbitrary browser traffic, the agent becomes reachable through a channel the organisation does not adequately govern.
• Command-Bearing Channel: A command-bearing channel is any interface that can change system state or trigger execution, such as terminal input or task-control messages. In identity terms, it is privileged access and should be authenticated, segmented, and logged separately from read-only telemetry.

Deepen your knowledge

Cross-origin WebSocket hijack and AI agent control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing developer tooling that reaches into terminals, repositories, and cloud credentials, it is worth exploring.

This post draws on content published by Oasis Security: Cross-Origin WebSocket Hijack in Cline's Kanban Server. Read the original.