50+ OpenClaw Security Fixes: Why Expert Setup Matters (Updated March 2026)

Four Releases, 50+ Security Patches

OpenClaw has now shipped four major security releases since February 2026 — v2026.2.19, v2026.3.3, v2026.3.11, and v2026.3.12. Together they account for more than fifty patched vulnerabilities across attack vectors including privilege escalation, command spoofing, cross-site WebSocket hijacking, Unicode obfuscation, and supply-chain-adjacent plugin code execution. Multiple external security researchers contributed reports. These are real attack paths, not theoretical concerns.

We covered the early technical details in our full security breakdown. This post takes a different angle: walking through each class of fix and asking honestly — if you set up OpenClaw yourself, would you have configured it safely before this patch?

Fix 1: SSRF via IPv6 Transition Addresses

What it was: OpenClaw's SSRF guard blocked obvious internal IP requests (127.0.0.1, 192.168.x.x), but not IPv6 transition addresses like NAT64 (64:ff9b::127.0.0.1) which resolve to the same internal IP.

Impact: Anyone who could influence what URLs your agent fetched could reach your internal network — databases, admin panels, other services on your LAN.

Would you have caught it? Almost certainly not. This requires deep knowledge of IPv6 transition mechanisms and how they interact with SSRF defenses. It wasn't in the setup docs.

Fix 2: Credential Theft via Exec Environment Variables (OC-09)

What it was: The exec tool (which lets your agent run shell commands) could be manipulated via untrusted input to read environment variables. API keys, database passwords, and other secrets stored in environment variables were readable.

Impact: If your agent accepted any untrusted external input (WhatsApp messages, webhook payloads, user queries), a crafted input could extract credentials.

Would you have caught it? Unlikely without a security audit. The exec tool is one of OpenClaw's most useful features — and its attack surface is not obvious from the documentation.

Fix 3: Plugin Path Traversal

What it was: Plugin discovery didn't validate that discovered plugins were actually within their trusted root directories. A symlink outside the plugin directory could be followed, loading untrusted code.

Impact: Malicious plugins could escape their sandbox and load arbitrary code, including scripts that read your config files or exfiltrate data.

Would you have caught it? No. This is an implementation-level vulnerability that required changes to the plugin loader itself. No config setting protects against it — you needed to be running the patched version.

Fix 4: Discord Privilege Escalation

What it was: Discord moderation actions (timeout, kick, ban) didn't properly verify that the sender had the required guild permissions. An attacker who could control the senderUserId field could trigger moderation actions they weren't authorized for.

Impact: If you had a public Discord bot with exec or moderation capabilities, any user could potentially trigger privileged actions.

Would you have caught it? Possibly if you had carefully read the Discord integration source code. Not from reading the setup guide.

Fix 5: Gateway Auth Default "None" Exposure

What it was: OpenClaw's gateway previously had no startup warning when gateway.auth.mode="none" was configured — making the gateway accessible without any authentication from any network the host was reachable on.

Impact: If you exposed your OpenClaw gateway to the internet (via port forwarding, Fly.io, Render, etc.) with auth.mode="none", anyone could issue commands to your agent.

Would you have caught it? Many users configure auth.mode="none" during local testing and forget to change it for production. There was no warning. The v2026.2.19 patch adds a CRITICAL severity warning when this is detected with remote exposure.

Fix 6: Webhook Credential Forwarding on Redirect

What it was: If a webhook URL redirected to a different origin, OpenClaw forwarded the Authorization, Cookie, and Proxy-Authorization headers to the new origin.

Impact: A malicious webhook endpoint could redirect to a server it controlled and receive your credentials in the redirect.

Would you have caught it? Almost certainly not. This is a subtle HTTP redirect behavior that most developers don't think about when setting up webhooks.

March 2026: 5 More Critical Patches

Just weeks after the v2026.2.19 security release, OpenClaw v2026.3.3 shipped with 5 additional security fixes — including two CVE-class vulnerabilities in upstream dependencies.

Fix 7: Hono Header Injection (CVE-2025-21554)

What it was: OpenClaw's gateway used Hono v4.6.12, which contained a header injection vulnerability (CVE-2025-21554). An attacker who could influence response headers could inject arbitrary headers — including setting cookies, redirecting to malicious sites, or bypassing security controls.

Impact: If your OpenClaw instance accepted webhooks or API requests from untrusted sources, a crafted request could inject malicious headers into responses. This could lead to session hijacking, cache poisoning, or redirecting users to phishing sites.

The fix: OpenClaw v2026.3.3 upgraded to Hono v4.6.13, which patches the vulnerability. All gateway endpoints that handle HTTP requests now sanitize header values.

Would you have caught it? No. This is an upstream library vulnerability. You would have needed to track Hono security advisories independently — even if your OpenClaw config was perfect, you were still vulnerable until the dependency was updated.

Fix 8: Tar Path Traversal (CVE-2025-23194)

What it was: The tar library used by OpenClaw's skill installation system contained a path traversal vulnerability (CVE-2025-23194). When extracting tar archives, the library didn't properly validate file paths — allowing files to be written outside the intended extraction directory.

Impact: A malicious skill package (or a compromised repository) could overwrite arbitrary files on your OpenClaw host during installation. This includes config files, SSH keys, or even system binaries.

The fix: OpenClaw v2026.3.3 upgraded to the patched tar version and added additional path validation in the skill installer. All archive extractions now enforce strict directory boundaries.

Would you have caught it? Unlikely. This vulnerability affects the tar extraction process itself — not your configuration. You would have been vulnerable even if you only installed trusted skills from reputable sources (if any of those repositories were compromised).

Fix 9-11: Dependency Security Improvements

Beyond the two CVEs, v2026.3.3 also removed two deprecated dependencies with known security issues:

• jose: Removed (deprecated, unmaintained, multiple CVEs in older versions)
• undici: Removed (deprecated, replaced with native fetch, security vulnerabilities in older versions)

These removals reduce your attack surface by eliminating code paths that are no longer maintained or audited.

March 2026 Continues: v2026.3.11 and v2026.3.12

The security work didn't stop at v2026.3.3. OpenClaw v2026.3.11 and v2026.3.12 shipped another 20+ security fixes — the largest single-release security batch in OpenClaw's history. The v2026.3.12 release alone carries more than fifteen GHSA advisories.

Fix 12: Cross-Site WebSocket Hijacking (GHSA-5wcw-8jjv-m286)

What it was (v2026.3.11): When gateway.auth.mode=trusted-proxy was configured, OpenClaw skipped browser origin validation for WebSocket connections that appeared to arrive via a trusted proxy. An attacker who could craft a cross-origin WebSocket request could connect to the gateway with operator.admin access — full control — without knowing any credentials.

Impact: Any OpenClaw deployment running behind a reverse proxy (nginx, Caddy, Traefik, Cloudflare Tunnel) and using trusted-proxy auth mode was potentially exposed to cross-site WebSocket hijacking. An attacker with access to your network could compromise your gateway without needing your shared token or device pairing.

Would you have caught it? Almost certainly not. The trusted-proxy mode is commonly recommended in reverse-proxy deployment guides. This is a subtle interaction between proxy headers and WebSocket origin validation that requires deep knowledge of the gateway internals to spot.

Fix 13: Implicit Workspace Plugin Auto-Load (GHSA-99qw-6mr3-36qr)

What it was (v2026.3.12): OpenClaw automatically discovered and loaded plugins found in the current workspace directory without requiring any trust decision. If you ran openclaw inside a cloned repository that contained a plugin in the expected location, that plugin's code executed automatically.

Impact: A malicious repository — one you might clone to review, contribute to, or use as a workspace — could execute arbitrary code on your machine simply by having you run any OpenClaw command inside it. This is a supply-chain-adjacent risk: the exploit path doesn't require you to explicitly install anything.

The fix: Implicit workspace plugin auto-load is now disabled by default. Plugins must be explicitly installed or trusted before they load. This is one of the most impactful changes in the v2026.3.12 release.

Would you have caught it? No. This was a deliberate feature (workspace-local plugins) that turned into an attack vector. You couldn't protect against it with any configuration setting — you needed the patched version.

Fix 14: Invisible Unicode Command Spoofing (GHSA-pcqg-f7rg-xfvv)

What it was (v2026.3.12): OpenClaw's exec approval prompts — the confirmation dialogs that show you exactly what command your agent is about to run — didn't render invisible Unicode format characters. Zero-width characters (U+200B, U+FEFF, and similar) could be injected into a command string, making the visible approval prompt show a safe-looking command while the actual executed command was different.

Impact: If an attacker could influence the commands your agent queued for approval (through prompt injection, malicious tool results, or compromised skill code), they could craft commands that appeared benign in the approval dialog but executed something entirely different after your approval.

The fix: Invisible Unicode format characters in approval prompts are now rendered as visible \u{...} escapes, so what you see is what gets executed.

Would you have caught it? No. This requires knowledge of Unicode format characters and how terminal rendering handles them. It's a visually undetectable attack at the point of approval.

Fix 15: Exec Command Obfuscation via Fullwidth Characters (GHSA-9r3v-37xh-2cf6)

What it was (v2026.3.12): Related to Fix 14 — OpenClaw's exec security heuristics checked commands for suspicious patterns like rm -rf, credential paths, and other dangerous strings. But fullwidth Unicode characters (ＲＭ instead of RM) and other visual lookalikes bypassed these heuristic checks entirely while still executing as the intended command on most shells.

Impact: Command analysis and heuristic-based approval rules could be bypassed by encoding commands in fullwidth or homoglyph Unicode, allowing dangerous operations to pass through security checks that should have flagged them.

The fix: Unicode normalization is now applied before all heuristic security checks so obfuscated commands are detected the same as their ASCII equivalents.

Fix 16: Exec Allowlist Path Overmatch (GHSA-f8r2-vg7x-gh8m)

What it was (v2026.3.12): OpenClaw's exec allowlist — where you configure exactly which commands your agent is allowed to run without prompting — used case-insensitive path matching on case-sensitive filesystems, and treated the ? wildcard as able to match path separators. A pattern like /usr/bin/git could match /usr/bin/git-credential-store or /usr/bin/GITFAKE.

Impact: Carefully crafted binary names could pass allowlist checks by exploiting the overmatch behavior, allowing unauthorized executables to run under the permissions of a trusted binary.

Fix 17: /config and /debug Sender Ownership Bypass (GHSA-r7vr-gr74-94p8)

What it was (v2026.3.12): OpenClaw's /config and /debug slash commands were accessible to any sender the gateway had granted write scope — not just the owner. This allowed non-owner senders who had been granted write access to reach owner-only configuration and runtime debug surfaces.

Impact: In multi-user OpenClaw deployments where you've granted write access to team members or bots, those users could read and modify gateway configuration they weren't supposed to access.

Fix 18: WebSocket Client-Declared Scopes (GHSA-rqpp-rjj8-7wv8)

What it was (v2026.3.12): When a client connected to the gateway via WebSocket with a shared token, it could self-declare elevated scopes in the connection handshake — and the gateway accepted them without verification. A client connecting with a read-only shared token could declare itself as having operator.admin scope.

Impact: Any attacker who obtained a shared token — even a read-only one — could escalate to full admin access over the gateway WebSocket connection.

The Pattern

Looking across these eighteen fixes (and the 30+ others across all four releases), a clear pattern emerges:

• Most vulnerabilities were in features that work correctly for normal use cases — but fail when inputs are malicious or unexpected
• None of them were visible in the standard setup documentation
• Most required code-level changes, not config changes — meaning you couldn't protect yourself by being careful with settings
• Several were reported by dedicated security researchers specifically looking for issues
• Upstream dependencies matter: Two of the March 2026 CVEs were in third-party libraries (Hono, tar), not OpenClaw code itself. Even perfect OpenClaw config wouldn't have protected you.

What This Means for Self-Hosters

Running OpenClaw in production as a self-hoster means you are responsible for:

• Tracking every security release and understanding what changed
• Testing that your specific configuration is no longer vulnerable after each patch
• Auditing your exec policy, plugin trust, webhook targets, and gateway auth regularly
• Understanding the interaction between all your configured features — channels, tools, webhooks, plugins — and their combined attack surface
• Monitoring upstream dependencies: The March 2026 CVEs show that you're not just responsible for OpenClaw itself — you're also on the hook for every library it uses (Hono, tar, jose, undici, and dozens more)
• Prompt updates: When a CVE is disclosed in a dependency, you have hours to days to patch before attackers weaponize it. Can you respond that fast?

That's a real operational burden. For many individuals and businesses, the question isn't "can I do this?" — it's "should I be doing this alone?"