[MEDIUM] Security Advisory: OpenClaw: HTTP operator endpoints lack browser-origin validation in trusted-proxy mode (openclaw)

OpenClaw, an npm package for handling HTTP services, ships a security gap in versions up to 2026.3.28. In trusted-proxy mode, its HTTP operator endpoints skip browser-origin validation. Attackers can exploit this for CSRF attacks if you run the vulnerable versions behind a trusted proxy like NGINX or Cloudflare. The maintainers patched it in version 2026.3.31 with commit 6b3f99a11f4d070fa5ed2533abbb3d7329ea4f0d, released on March 31, 2026.

This matters because trusted-proxy mode tells the server to trust headers from upstream proxies for client IP and origin details. Without origin checks on operator endpoints—likely admin or debug paths meant for internal ops—browsers from those proxies can trigger unwanted actions. Think form submissions or API calls forged from malicious sites. The maintainers rate it medium severity and narrow scope: it requires identity-bearing browser deployments via trusted proxy, not the default shared-secret model. Fair assessment—it’s real but won’t burn the house down unless you misconfigure.

Vulnerability Breakdown

OpenClaw’s operator endpoints handle privileged operations. In standard mode, they demand shared secrets over HTTP. Switch to trusted-proxy, and it leans on proxy-supplied origins. But no validation means any browser hitting the proxy can POST to those paths. Vulnerable range: all tags <=2026.3.28. Latest safe version: 2026.3.31.

Reproduce it? Deploy OpenClaw behind a proxy marked trusted. Load an operator endpoint in a browser. Craft a malicious page with a form targeting that endpoint via the proxy. Submit—no origin block. CSRF classic. Reported by @AntAISecurityLab, who gets credit from the OpenClaw team. No public PoC yet, keeping it responsible disclosure-style.

Context: npm packages like this often power backend services in Node.js apps. OpenClaw targets claw-specific ops—tightly scoped, low download count implied by obscure name. Still, if your stack uses it (check npm ls openclaw), audit deployments. Future dates (2026) suggest bleeding-edge or internal versioning, but tags exist on npm.

Real-World Impact

Why care? Proxies are everywhere—AWS ALB, Vercel, your homelab Traefik. Trusted-proxy mode saves config headaches but exposes origin trust. Here, it bites operator endpoints. Attack needs:

• Victim browses your app via trusted proxy.
• Attacker site convinces victim to POST to operator path.
• No origin header check = action fires.

Skeptical take: Narrow because most users stick to shared-secret auth. No mass RCE or data dump. But in browser-heavy proxies (e.g., corporate SSO flows), it escalates. CVSS-like medium fits—exploitability medium, impact low unless ops endpoints nuke data. Broader lesson: Proxy trust demands endpoint hardening. Always validate origins client-side and server-side.

Scan your deps:

npm audit

might flag it post-patch. Or yarn audit. If pinned old, you’re exposed till upgrade.

Fix It Now

Upgrade to >=2026.3.31. Pin in package.json:

{
  "dependencies": {
    "openclaw": "^2026.3.31"
  }
}

Run npm update openclaw. Verify with npm ls openclaw. The fix commit adds origin validation in trusted-proxy paths—simple but effective. Test post-upgrade: Proxy traffic should now reject cross-origin browser requests.

Mitigate interim: Disable trusted-proxy or block browser access to operator endpoints via proxy rules (e.g., NGINX location /operator/ { allow internal; deny all; }). Rotate secrets if compromised. Watch npm for OpenClaw updates; maintainers triage fast here.

Bottom line: Patch exists, risk contained. But it flags sloppy proxy assumptions in niche packages. In security, “trusted” means verify twice. If you’re building HTTP services, bake origin checks from day zero—browsers lie, proxies amplify.