OpenClaw’s Authentication Blind Spot

â–¶ Watch (8:45)

The HTTP API endpoint /slash requires no authentication token. It serves a static page with client-side JavaScript. That JavaScript runs applySettingsFromUrl, which reads a gatewayUrl parameter from the URL. The client then connects to whatever backend that parameter specifies. Because there is no token, an attacker can craft a GET request to /slash with a malicious gateway URL. The victim’s browser loads the static page and JavaScript executes. Alone, this feature is innocuous.

Chaining Three Benign Features

â–¶ Watch (11:00)

The JavaScript performs an auto-login. It sends the user’s OpenClaw authentication token in the websocket handshake to the gateway specified in the URL. If an attacker controls that gateway, the token is exfiltrated. Three features—static page without CSRF protection, URL-defined gateway, and auto-login—are individually harmless. Chained together, one click on a crafted link sends the admin token to the attacker. The attacker now has full access to the victim’s OpenClaw instance.

Bypassing the Localhost Barrier

â–¶ Watch (13:37)

A local OpenClaw instance behind a firewall cannot be reached directly by an external attacker. Levin’s bypass: instead of sending the victim to the malicious gateway URL directly, the attack runs fully in the browser. The victim visits evilsite.com. That site spawns two hidden browser windows. One window performs the token exfiltration from the local OpenClaw. The other window uses the stolen token to talk to the local OpenClaw via websockets. Websockets do not enforce the Same-Origin Policy in older Chrome versions, so the attacker’s page can connect to localhost:... without restriction.

Bypassing Four Defenses

â–¶ Watch (16:01)

OpenClaw’s user approval prompts, sandboxing, and pairing mode are designed to stop a rogue LLM, not an external attacker. With the admin token, Levin disabled user approvals via the API. He patched the sandbox configuration through the websocket interface. The pairing mode uses a shared key per client, not per gateway. That means the same key is sent to a malicious gateway. Levin man-in-the-middled the handshake to authenticate his session. All four defenses fell.

Proof of Concept Demo

â–¶ Watch (19:52)

Levin ran a live demo. He started a local OpenClaw instance with all defenses enabled. He opened a phishing site that mimicked a refund page. After clicking the trigger, the exploit launched two background windows. Within seconds, a calculator application appeared on the host. The demo confirmed 1-click RCE against the most secure configuration available at the time.

Q&A

What patching approach do you recommend? Strengthen the authentication layer—pairing mode with per-client per-gateway keys would have blocked the token relay. ▶ 22:31

Would two-factor authentication prevent this? No, if the post-login session token is exfiltrated, 2FA during login does not protect it. â–¶ 24:15

How did you discover the chain? Going deep on each “so what” step and collecting primitives, then testing defenses one by one. ▶ 24:52

Are all agentic systems inherently insecure right now? Likely yes, due to complexity and the lack of mature security practices. OpenClaw does well to flag risks, but broad access creates many attack surfaces. â–¶ 27:30

Notable Quotes

“by chaining three features that independently aren’t so bad and also as we’ll see later have different defenses and other walls. We see that one click can lead the authentication token.” Mav Levin · ▶ 12:06

“websockets don’t comply with SOP as of the most recent Chrome which fixed this. But that basically meant if you’re operating over websockets, any site could talk with any site however much it wanted.” Mav Levin · ▶ 14:48

“I broke four defenses and we see that agency securing what we trust so awesomely because it’s so great to be able to just prompt for whatever we need we see that comes with some needed security work.” Mav Levin · ▶ 19:22

Key Takeaways

  • Three benign features (no-token login page, URL-defined gateway, auto-login) chained to leak the admin token.
  • Websocket SOP bypass allows the exploit to run against localhost without external connectivity.
  • Existing defenses (sandboxing, user approvals, pairing mode) fail when the attacker controls the admin session.

About the Speaker

Mav Levin (@mavlevin) focuses on finding zero-day vulnerabilities in software and developing autonomous AI security research agents. Previously he was at Anthropic, Unit 8200, and received his undergraduate degree from Stanford in Computer Science.