DEV Community

LPW
LPW

Posted on • Originally published at pipelab.org

"CVE-2026-25253: WebSocket hijacking turns your AI agent into an attack tool"

#security #ai #websocket #mcp

OpenClaw is an open-source AI agent platform. It connects agents to tools, other agents, and the internet through a gateway server.

CVE-2026-25253 (CVSS 8.8) is a cross-site WebSocket hijacking vulnerability in the OpenClaw gateway. A single malicious link gives an attacker full control of your agent's tools, sandbox settings, and host access. The vulnerability was disclosed by depthfirst.com and independently by Ethiack. OpenClaw published a vendor advisory and the fix is in version 2026.1.29 and later.

The attack chain

Five steps. Each one builds on the last.

Step 1: Click a link. The victim (someone running an OpenClaw agent) clicks a link from a chat message, email, or forum post. The attacker's page loads in their browser.

Step 2: WebSocket to localhost. The attacker's JavaScript opens a WebSocket connection to the victim's OpenClaw gateway. Per the NVD description, the gateway obtains a gatewayUrl from a query string and automatically connects without prompting, sending a token value.

Step 3: Steal the auth token. The attacker's page receives the gateway authentication token via the WebSocket connection.

Step 4: Disable the sandbox. Using the stolen token, the attacker sends tool calls that disable OpenClaw's safety guardrails and sandbox restrictions.

Step 5: Remote code execution. The attacker invokes node.invoke (or similar execution tools) to run arbitrary commands on the host machine.

The whole chain takes seconds. The victim doesn't see anything unusual. Their agent is now the attacker's tool.

Why this matters beyond OpenClaw

This CVE is OpenClaw-specific (missing origin validation on WebSocket handshake), but the pattern isn't. Any AI agent platform that exposes a WebSocket or HTTP endpoint on localhost is a target for cross-site attacks. The agent has credentials, tool access, and network reach. A hijacked session inherits all of it.

The attack doesn't require any vulnerability in the AI model. It doesn't require prompt injection. It's a classic web security flaw applied to an agent gateway, and it gives the attacker the agent's full capability set.

Defense in depth: catching downstream exploitation

Origin validation on the WebSocket handshake is the right fix for the CVE itself (and the upstream patch addresses this). But defense-in-depth means catching exploitation attempts even if the handshake-level fix isn't deployed yet or is bypassed by a future variant.

Pipelock sits between the agent and the gateway, scanning all MCP traffic in both directions. Here's what each scanning layer catches in this attack chain:

Attack step What pipelock does Scanning layer
Token theft via WS handshake Not mitigated (requires WS listener mode, not yet implemented) (planned)
Sandbox disable via tool call Tool policy blocks dangerous tool invocations by name/pattern MCP tool policy
RCE via node.invoke Deny rules for shell/exec tool patterns MCP tool policy
Data exfiltration via tool args Input scanning catches secrets in outbound tool arguments MCP input scanning
Injection in tool responses Response scanning detects injection patterns in tool results MCP response scanning
Read-then-exfil sequences Chain detection matches multi-step attack patterns Chain detection
Outbound HTTP exfiltration 9-layer URL scanning pipeline, DLP on all outbound requests HTTP proxy

When MCP traffic routes through pipelock, it mitigates the downstream steps in this chain: tool policy, input scanning, response scanning, chain detection, and DLP all fire on post-compromise activity. The initial token theft (the WS handshake itself) is the step that requires the upstream origin validation patch.

One-command setup

The generate mcporter command wraps your existing OpenClaw config with pipelock scanning:

# Install
brew install luckyPipewrench/tap/pipelock

# Generate a scanning config (or use one of the presets in configs/)
pipelock generate config --preset balanced > pipelock.yaml

# Wrap all MCP servers in your config
pipelock generate mcporter -i mcporter.json --in-place --backup
Enter fullscreen mode Exit fullscreen mode

Your agent's MCP traffic now routes through pipelock before reaching the OpenClaw gateway. The generator is idempotent (running it twice produces identical output) and creates a .bak backup.

Before wrapping:

{
  "mcpServers": {
    "openclaw": {
      "command": "openclaw",
      "args": ["connect", "--gateway", "ws://localhost:3000/mcp"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

After wrapping:

{
  "mcpServers": {
    "openclaw": {
      "command": "pipelock",
      "args": [
        "mcp", "proxy",
        "--config", "/path/to/pipelock.yaml",
        "--", "openclaw", "connect", "--gateway", "ws://localhost:3000/mcp"
      ]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Pipelock launches the original command as a subprocess and intercepts all MCP messages in both directions. The agent doesn't know pipelock is there. No code changes to your agent or the gateway.

Kubernetes: sidecar pattern

For production deployments, run pipelock as a sidecar container. The agent container has secrets but routes all traffic through pipelock. NetworkPolicy enforces the isolation at the cluster level:

# Illustrative NetworkPolicy. Tighten for your environment.
# Intent: agent can only reach the pipelock sidecar (same pod, port 8888).
# Hardening: lock DNS egress to kube-dns/coredns only.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress
spec:
  podSelector:
    matchLabels:
      app: agent
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
      ports:
        - port: 53
          protocol: UDP
    - to:
        - podSelector:
            matchLabels:
              app: agent
      ports:
        - port: 8888
Enter fullscreen mode Exit fullscreen mode

The full K8s deployment manifest (init container, sidecar, volumes) is in the OpenClaw deployment guide.

What this doesn't cover

Honest limitations:

  • WebSocket handshake interception. Pipelock's MCP proxy currently works as a stdio wrapper or HTTP upstream, not as a WebSocket listener. It doesn't inspect the initial WS handshake, so it can't enforce origin validation. That's the one step in the CVE chain that requires the upstream patch. WS listener mode is planned.
  • Zero-day gateway vulnerabilities. If a new gateway vulnerability bypasses pipelock's known tool policy rules, those rules need updating. Pipelock's scanning is pattern-based, not semantic. New attack techniques need new patterns.
  • Agent-to-agent lateral movement. If the compromised agent spawns a new agent process that doesn't route through pipelock, the second agent runs unscanned. Container networking or namespace isolation prevents this (the spawned process inherits the network restrictions).

The broader takeaway: agent platforms need the same layered security as web applications. Authentication (origin validation) stops the initial compromise. Authorization (tool policies) limits damage. Content inspection (DLP, injection scanning) catches what authorization allows. No single layer is enough.

Full deployment guide: docs/guides/openclaw.md

If you find a gap in the mitigation mapping, open an issue.

Top comments (0)