Notifications
Clear all
Topic starter
04/06/2026 3:03 pm
TL;DR: A CVSS 9.7 flaw in Cline’s local kanban server let any website connect cross-origin, stream workspace data, inject terminal commands, and disrupt tasks, exposing developer environments and AI agent sessions to silent browser-based abuse, according to Oasis Security. The issue shows why agent-facing local services need origin checks, authentication, and tighter runtime policy.
NHIMG editorial — based on content published by Oasis Security: Cross-Origin WebSocket Hijack in Cline's Kanban Server
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full report
Oasis Security's full research covers the operational detail this post intentionally leaves for the source:
- Packet-level description of the vulnerable localhost WebSocket flow and how the browser reached it.
- Proof-of-concept command injection and task-termination behaviour that shows the control-plane impact.
- Patch context for version 0.1.66 and the specific checks the vendor added in response.
- Technical notes on why browser same-origin expectations do not protect this local listener.
👉 Read Oasis Security's analysis of the Cline cross-origin WebSocket hijack →
Cline WebSocket hijack: what it means for AI agent governance?
Explore further
04/06/2026 3:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cross-origin WebSocket hijack in Cline exposes agent trust gaps
