How a Website Can Hijack Your Local AI Agent in Under a Second

OpenClaw passed 200K GitHub stars. It runs locally, connects to your filesystem, your API keys, and your integrations. Then CVE-2026-25253 dropped: CVSS 8.8. Any website you visit can take full control of it. The fix exists — but the underlying pattern affects every locally-running AI agent.

---

What happened

OpenClaw is an open-source AI agent platform. It handles WhatsApp, Telegram, Discord, Slack, and more. It reads files, runs shell commands, manages calendars, and spawns sub-agents — all from a chat message. It runs a WebSocket-based gateway on localhost that acts as the control plane for the entire agent.

In January 2026, security researchers 0xacb and mavlevin reported a critical flaw: OpenClaw's Control UI accepted a gatewayUrl parameter from the browser's query string without validation and automatically connected to it, sending the stored authentication token in the WebSocket payload. An attacker only needed to get a user to click a crafted link. One click, and the attacker had operator-level access to the gateway API — enabling arbitrary configuration changes and code execution on the host.

GHSA-g8p2-7wf7-98mq classified the impact as 1-click remote code execution via authentication token exfiltration.

In February 2026, the Oasis Security Cyber Research Team dug deeper and named the vulnerability class ClawJacked. They found three chained weaknesses that turned the localhost gateway into an open door:

1. No WebSocket Origin validation. The gateway's WebSocket server does not check the Origin header. Any website loaded in the user's browser can open a WebSocket connection to localhost — browsers allow this because WebSocket connections are not subject to Same-Origin Policy or CORS.

2. Localhost exempted from rate limiting. The gateway completely exempts local connections from rate limiting. Failed authentication attempts are neither counted, throttled, nor logged. An attacker's script can brute-force the gateway password at hundreds of attempts per second.

3. Auto-approved device registration. The gateway auto-approves new device registrations originating from localhost without prompting the user. Once the password is brute-forced, the attacker is silently registered as a trusted device.

The result: an attack chain that requires zero user interaction beyond visiting a webpage. The malicious site opens a WebSocket to localhost. JavaScript brute-forces the gateway password. The attacker registers as a trusted device. Full control — agent commands, configuration data, connected node enumeration, and application logs. Oasis Security described the post-compromise state as "equivalent to full workstation compromise."

The user sees nothing.

OpenClaw's team patched the vulnerability within 24 hours. Version 2026.1.29 addressed the token exfiltration vector. Version 2026.2.25 addressed the brute-force and device-pairing issues. Credit to the OpenClaw team for the response speed — but the underlying pattern extends far beyond a single project.

---

Why "localhost = safe" is a myth

The core assumption behind ClawJacked is one that most developers share: if a service only listens on localhost, it's not reachable from the internet.

For HTTP, that's largely true. Browsers enforce the Same-Origin Policy on HTTP requests, and CORS restricts cross-origin responses. But WebSocket connections are not subject to these protections.

CWE-1385 (Missing Origin Validation in WebSockets) explains why: cross-origin restrictions target HTTP response data, but WebSockets work over the WS/WSS protocols. No HTTP response data is required to complete the WebSocket handshake, and subsequent data transfer happens over WebSocket, not HTTP. The browser sends an Origin header during the handshake, but validating it is entirely the server's responsibility. Most don't.

This means any website you visit — a malicious page, a compromised blog, a phishing email with an embedded link — can open ws://localhost:PORT and establish full bidirectional communication with any local service that accepts WebSocket connections without Origin validation.

This is not a theoretical concern. It's a documented vulnerability class called Cross-Site WebSocket Hijacking (CSWSH). Unlike standard CSRF, which can only trigger actions, CSWSH provides bidirectional communication — the attacker can both send messages and receive server responses, enabling real-time data exfiltration.

Here's what several popular locally-running AI tools look like from a network perspective:

Tool	Default Binding	Auth by Default	Uses WebSocket
OpenClaw Gateway	localhost	Password (localhost exempted from rate limiting)	Yes
Ollama	localhost:11434	None	No (HTTP API)
Open WebUI	localhost:8080	Session-based	Yes
LM Studio	localhost:1234	None	No (HTTP API)
MCP Servers (stdio)	N/A (stdin/stdout)	N/A	Not network-exposed
MCP Servers (SSE/HTTP)	Varies	Varies	Sometimes

This isn't an exhaustive audit of each tool. It's a pattern observation: tools designed for local use consistently assume that localhost access implies trusted access. That assumption is false in any environment where a browser is running.

This pattern is not new. CSWSH has been exploited in developer tools, SIEM consoles, and gaming clients since at least 2018. What's new is the scale of the prize: AI agents running on localhost now hold credentials, filesystem access, and code execution capabilities that make them the single highest-value target on a developer's machine.

The root cause is not a single bug. It's a trust model that doesn't hold.

---

The blast radius

When a traditional web application gets compromised, the attacker gains access to that application's data and capabilities. When an AI agent gets compromised, the attacker gains access to everything the agent can reach.

AI agents aren't normal applications. They hold persistent, broad access to:

• Filesystem: SSH keys (~/.ssh/), environment files (.env), cloud credentials (~/.aws/credentials, ~/.config/gcloud/)
• API tokens: For multiple services simultaneously — GitHub, Slack, email, databases
• Integration permissions: Git repos, calendar, messaging platforms, CI/CD pipelines
• Code execution: Shell commands, script interpreters, container runtimes

A compromised agent doesn't just leak data from one service. It becomes the attacker's proxy into your entire development environment. And because agents maintain persistent sessions, the attacker doesn't need to maintain their own access — the agent does it for them. Send a command once, and the agent executes it with all its existing permissions. No lateral movement required. No privilege escalation needed. The agent already has the access.

And ClawJacked was not an isolated incident. OpenClaw disclosed 9 CVEs in early 2026, spanning remote code execution, authentication bypass, SSRF, command injection, and path traversal:

CVE	Type	CVSS	Patched In
CVE-2026-25253	WebSocket token exfiltration / RCE	8.8	2026.1.29
CVE-2026-28363	safeBins validation bypass	9.9	2026.2.23
CVE-2026-25593	RCE via cliPath injection	—	2026.1.20
CVE-2026-24763	Docker sandbox command injection	—	—
CVE-2026-25157	macOS SSH handler command injection	—	2026.1.29
CVE-2026-25475	Local file inclusion via MEDIA path	—	2026.1.30
CVE-2026-26319	Webhook authentication bypass	7.5	—
CVE-2026-26322	SSRF via gateway tool	7.6	—
CVE-2026-26329	Path traversal in browser upload	—	—

Nine CVEs. One project. One quarter. Including a CVSS 9.9 critical that allowed bypassing execution allowlists via GNU long-option abbreviations.

Internet scans found 42,665 exposed OpenClaw instances, with 5,194 actively vulnerable. Separately, approximately 1,000 instances were running without any authentication at time of discovery.

The supply chain around OpenClaw compounds the risk. Independent analyses of the ClawHub skill marketplace found 36.82% of 3,984 skills contained security flaws, with 76 confirmed malicious payloads. A separate Cisco study of 31,000 skills found 26% contained vulnerabilities including insecure API key handling and command injection.

This is not a "one project had bugs" story. This is a vulnerability class. The pattern — localhost trust, missing WebSocket validation, broad agent permissions — repeats across the ecosystem.

---

How to protect yourself

This is the section that matters. Whether you use OpenClaw or any other locally-running AI agent, these steps apply.

If you run OpenClaw

Check your version:

openclaw --version

If the output shows anything before 2026.2.25, you are running a vulnerable version.

Update immediately:

npm update -g clawdbot
# or
docker pull openclaw/openclaw:latest

Run the built-in security checker:

openclaw doctor --fix

This detects risky configurations — unauthenticated gateways, missing TLS, insecure DM policies — and can auto-fix many of them.

Rotate credentials. If you ran a vulnerable version at any point, assume your gateway token was exfiltrable. Rotate:

• Any API keys configured in OpenClaw
• Tokens for connected services (Slack, GitHub, email, calendar)
• SSH keys if the agent had filesystem access
• Cloud provider credentials (~/.aws/credentials, GCP service accounts)

Don't skip this step. A compromised token doesn't announce itself.

Five defensive patterns for any local AI agent

These apply to OpenClaw, Ollama, Open WebUI, MCP servers, or any other agent running on your machine.

1. Run agents in containers, not on your host

A container provides filesystem isolation, network control, and capability restrictions. A compromised agent in a container cannot read your ~/.ssh/ directory or your .env files — unless you explicitly mount them.

# docker-compose.yml — isolated AI agent
services:
  ai-agent:
    image: your-agent-image:pinned-version
    networks:
      - isolated
    volumes:
      - ./workspace:/app/workspace  # Only this directory is accessible
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp:size=100M

networks:
  isolated:
    driver: bridge
    internal: true  # No outbound internet access

Key settings:

• internal: true blocks all outbound network access. The agent can't phone home.
• read_only: true prevents filesystem writes outside mounted volumes.
• cap_drop: ALL removes Linux capabilities the agent doesn't need.
• no-new-privileges prevents privilege escalation via setuid binaries.

If the agent needs internet access for specific APIs, use an egress proxy that allowlists only the required domains.

2. Disable auto-approve mode

Many AI agents offer a "YOLO mode" or auto-approve setting that executes tool calls without confirmation. This is convenient. It's also the fastest path from prompt injection to code execution.

If your agent can run shell commands, write files, or call external APIs, require explicit approval for each action. The seconds you spend confirming are cheaper than the hours you spend rotating credentials after a compromise.

3. Audit your open ports

Know what's listening on localhost. Run this periodically:

# macOS / Linux — show all listening ports with process names
lsof -i -P -n | grep LISTEN

# Alternative — just TCP listeners
ss -tlnp        # Linux
netstat -an | grep LISTEN   # macOS

Look for unexpected services. If you don't recognize a port, investigate before dismissing it. Every listening port is a potential attack surface for Cross-Site WebSocket Hijacking.

4. Use network namespaces or firewall egress rules

If you can't containerize, restrict network access at the OS level:

# macOS — block a specific process from outbound connections
# Add to /etc/pf.conf:
# block drop out on en0 proto tcp from any to any user _agent_user

# Linux — restrict outbound traffic for a specific user
# iptables -A OUTPUT -m owner --uid-owner agent-user -j DROP

The principle: AI agents should have minimum viable network access. If an agent only needs to call the OpenAI API, it shouldn't be able to reach your internal network, DNS servers, or metadata endpoints.

5. Inspect agent configs before opening cloned repos

Cloned repositories can contain agent configuration files that execute on open:

• .claude/ — Claude Code settings and hooks
• .cursor/ — Cursor AI rules and configuration
• .github/copilot/ — Copilot instructions
• .vscode/ — VS Code tasks and extensions
• mcp.json, mcp_config.json — MCP server definitions

Before opening a cloned repo in an AI-enabled IDE, check these directories. A malicious mcp.json can point to an attacker-controlled server. A crafted .cursor/rules file can inject instructions into every prompt. These are not hypothetical — they are documented attack vectors.

# Quick scan of a cloned repo before opening it
find . -maxdepth 2 \( -name ".claude" -o -name ".cursor" -o -name "mcp.json" -o -name "mcp_config.json" \) -print

---

What this means for the ecosystem

ClawJacked is one vulnerability in one project. The disclosure-to-patch cycle worked. But the industry is deploying AI agents faster than it's securing them.

The exposure is measured, not estimated. Trend Micro's research found 492 MCP servers with no client authentication or traffic encryption, collectively exposing 1,402 tools. 90% of those tools provide direct read access to data sources. Broader scans in February 2026 found over 8,000 MCP servers visible on the public internet, many with admin panels and debug endpoints exposed without authentication. The root cause: default configurations binding to 0.0.0.0 instead of 127.0.0.1.

Standards are coming, but not yet here. NIST announced the AI Agent Standards Initiative on February 17, 2026, organized under the Center for AI Standards and Innovation (CAISI). The initiative has three pillars: industry-led agent standards development, community-led open source protocol work, and research into AI agent security and identity. CAISI's Request for Information on AI Agent Security closes March 9, 2026. If you build or deploy AI agents, respond to it.

The risk taxonomy exists. The OWASP Top 10 for Agentic Applications maps ClawJacked directly to two categories:

• ASI01 — Agent Goal Hijack: After compromising the gateway, the attacker replaces the agent's objectives — sends commands, extracts data, pivots to connected services. OWASP calls this "the ultimate failure state" where "your asset becomes a weapon."
• ASI05 — Unexpected Code Execution: The agent has code execution capabilities that become the attacker's capabilities post-compromise. OpenClaw's shell access, file operations, and sub-agent spawning all fall under this risk.

The framework is published. The detection tooling is emerging. What's missing is adoption. Most teams deploying AI agents have not read the OWASP Agentic Top 10, are not tracking AI agent CVEs, and are not applying the same security rigor to agent infrastructure that they apply to web applications.

---

The bottom line

ClawJacked is fixed. Update OpenClaw, rotate your credentials, and audit your setup.

But the pattern — localhost trust, missing WebSocket validation, broad agent permissions, no network isolation — is not fixed. It exists in tools across the ecosystem, and it will produce more CVEs.

The practical defense is layers:

1. Containerize agents. Don't run them on your host.
2. Audit what's listening on localhost. Know your attack surface.
3. Disable auto-approve. Keep a human in the loop.
4. Scope agent credentials. Least-privilege tokens. Rotate regularly.
5. Inspect cloned repos. Check for agent configs before opening.

None of this requires enterprise tooling. It requires treating AI agents with the same caution you'd give any other software that has access to your files, your credentials, and your API keys.

For a complete AI agent security checklist, see oktsec.com/ai-agent-security.

The fix for ClawJacked exists. The fix for the pattern doesn't — yet.

---

Sources: NVD CVE-2026-25253 · GHSA-g8p2-7wf7-98mq · Oasis Security · The Hacker News · CWE-1385 · Trend Micro · NIST CAISI · OWASP Agentic Top 10 · PortSwigger CSWSH

Comments

[Gijs Jansen]

This vulnerability chain actually made me aware of the risks of using localhost. Mostly I have only built API’s as secondary because I am mainly a cloud data engineer. But I do run a lot of tooling on localhost that helps me get my job done. And these tools are processing company data when I am developing. I guess I have been one of those myth believers. Now I at least know one more thing to look for in these tools to see if they are actually safe.