1-Click Complete Device Compromise via Browser Visit

A security researcher disclosed the first 1-click exploit against OpenClaw: visiting a malicious URL from any browser on the same machine exfiltrated SSH keys, API keys, and source files, and granted full shell access — zero misconfiguration required.

CONFIRMED

🔓 SECURITY LEAK💾 DATA LOSS

Incident Brief

OpenClaw's local gateway bound to 127.0.0.1 and treated all same-origin requests as trusted — including those initiated by a browser visiting a remote page that issued XMLHttpRequest or fetch() calls against localhost. The gateway exposed file-read, key-dump, and shell-exec endpoints without requiring any authentication token. A victim visiting a crafted page could, in the span of one click, leak their entire ~/.ssh directory, all stored API keys, and have a reverse shell opened. The disclosure was the first public 1-click weaponization of the previously-theoretical localhost-trust flaw.

Root Cause

The Actual Culprit

The gateway used loopback-binding as its sole authentication check. CORS was not enforced on sensitive endpoints, and no CSRF token or Origin-header validation was in place for shell/key/file operations.

What Was Done

[OK]Per-session CSRF token required for all privileged endpoints

[OK]Strict Origin-header allowlist (gateway UI only)

[OK]Binding changed to a unix socket by default instead of TCP loopback

[OK]Dangerous endpoints moved behind explicit user confirmation prompt

Lessons Learned

lock

Localhost ≠ authenticated

Any process on the same machine — including a browser visiting an attacker's page — can reach your loopback service. 'It's bound to 127.0.0.1' is not an authentication strategy.

shield

Treat browser-origin requests as untrusted by default

CSRF tokens, Origin validation, and SameSite cookies are not enterprise-only concerns. A single web visit should not be able to exfiltrate your ~/.ssh.

alert-triangle