OpenClaw Security Check: What to Do Right Now (CVE-2026-33579 & CVE-2026-34426)

Two serious vulnerabilities in OpenClaw were disclosed in the last 24 hours, and the discourse has gotten loud fast. Ars Technica called it. CertiK published a report. Reddit is doing what Reddit does.

At ClawMentor, we're not going to amplify the panic — and we're not going to minimize it either. Here's exactly what you need to know, the specific checks to run, and the steps to take.

What Happened

On April 3–4, 2026, two CVEs were disclosed affecting OpenClaw's gateway and approval systems.

CVE-2026-33579 involves the /pair approve command accepting unauthenticated requests. Documentation describes an authentication gate — that gate doesn't exist in versions prior to commit b57b680. On installations running without explicit auth configuration, an attacker can obtain base pairing rights without credentials.

CVE-2026-34426 involves OpenClaw's approval and execution paths normalizing environment variables differently. Under specific conditions, this inconsistency allows an approval granted in one context to be invoked in another — effectively bypassing the approval mechanism.

Both have been patched in the latest release. The community Forge thread has been active since early this morning. Here's the fix.

Are You Actually at Risk?

Not every OpenClaw installation is equally exposed. Run through this quick assessment:

High Risk — Act Now

• Self-hosted, gateway exposed to the internet
• Authentication not explicitly configured
• Running a version prior to commit b57b680
• Especially if /pair approve is accessible from outside localhost

Moderate Risk — Check and Patch

• Self-hosted, gateway on localhost or LAN only, but auth is not explicitly enabled
• Running any pre-patch version, even in a “private” setup — the env normalization issue can still be triggered locally

Lower Risk — Still Worth Patching

• Self-hosted with authentication explicitly enabled and network restricted to localhost or a known subnet
• You're still pre-patch, so update — but your exposure window is narrower

Minimal Risk

• Fully air-gapped or localhost-only with no remote access and auth enabled
• You should still patch, but you're not the urgent case

One key signal: if you have never touched your auth configuration after the default install, treat yourself as high risk until you've confirmed otherwise.

Immediate Checks

Run these now, in this order.

1. Check your current OpenClaw version and auth status

openclaw status --deep

Look for authentication: enabled in the output. If you see authentication: disabled or the key is absent, your gateway is unauthenticated.

2. Check your gateway's network exposure

openclaw gateway status

Confirm whether the gateway is binding to 0.0.0.0 (all interfaces, potentially exposed) or 127.0.0.1 (localhost only). If it's 0.0.0.0 on a machine with a public IP, that's your immediate priority.

3. Inspect your exec approvals file for corrupted policy enums

cat ~/.openclaw/exec-approvals.json

Look for policy values that are anything other than allow-once, allow-always, or deny. Unexpected or malformed enum values can indicate CVE-2026-34426 has been exploited or triggered in your environment.

4. Update to the latest patch

# Pull the latest version — exact command depends on your install method
# Check the OpenClaw Forge thread or official docs for your platform's update path
openclaw --version

Confirm you're on a version that includes commit b57b680 or later.

5. Check for unexpected paired clients

openclaw status --deep

Review any connected clients in the output. If you see pairing entries you don't recognize, treat that as a signal of potential exploitation.

The Two CVEs, Explained Simply

CVE-2026-33579 — Unauthenticated Pairing

The short version: the docs said there was a lock on the door. There wasn't.

/pair approve is the mechanism that grants new clients pairing rights with your OpenClaw gateway. The intended design requires authentication before approval. In practice, the auth check was documented but not enforced in the code path.

On an exposed, unauthenticated instance, an attacker who can reach your gateway URL can submit a pairing request and have it approved without a password, token, or any credential. Once paired, they have base-level access to interact with your gateway.

What “base pairing rights” means in practice: it's the starting point, not root access. But it's enough to be a serious problem — especially in conjunction with CVE-2026-34426.

The fix: patch, enable explicit authentication, and restrict network access.

CVE-2026-34426 — Approval Bypass via Env Normalization

The short version: OpenClaw processes approval grants and command executions through two different code paths, and those paths normalize environment variables differently.

When an approval is granted, that approval is recorded with environmental context. When the command executes, the execution path evaluates a slightly different representation of the same environment. Under specific conditions — particularly when variable names contain certain characters or casing — the execution path treats a pre-granted approval as valid for a command that wasn't actually approved.

This is subtler than CVE-2026-33579 and harder to exploit without prior access, but combined with the pairing vulnerability, the risk compounds.

What this means in your exec-approvals.json: if you see entries with malformed policy values, or approvals for commands you don't recognize, take that seriously.

The fix: patch. After patching, audit your approvals file and clear any suspicious entries.

Hardening Checklist

Go through this list after patching. These aren't vague suggestions — each one is a concrete action.

• Update to latest patch — confirm your version includes commit b57b680 or later.
• Enable gateway authentication — run openclaw status --deep and confirm authentication: enabled.
• Restrict gateway to localhost or known subnet — unless you have a specific reason to expose the gateway externally, bind it to 127.0.0.1.
• Audit your exec-approvals.json — remove entries with unexpected policy values or unrecognized commands.
• Review paired clients — verify every paired client is one you recognize and authorized.
• Revoke unexpected pairings — if you find clients you don't recognize, remove them.
• Use Tailscale or a VPN for remote access — don't expose your gateway port directly if you can avoid it.
• Set a strong gateway auth token — use a long randomly-generated token and don't reuse passwords.
• Enable firewall rules for the gateway port — allow access only from trusted IPs.
• Subscribe to OpenClaw security announcements — these disclosures moved fast.
• Schedule periodic config reviews — run openclaw status --deep monthly.
• Document your setup — especially if you're running a multi-agent configuration.

What ClawMentor Covers

Since early 2026, ClawMentor has been publishing update packages that include security posture guidance specific to how OpenClaw configurations evolve week to week. The kind of drift that leads to situations like this — auth defaults, network exposure, approval file hygiene — is exactly what our update packages track.

If you want a structured way to stay ahead of issues rather than react to them, your first update package is free. You get it, you apply it, you see what it does. Then decide if the ongoing cadence fits how you work.

The Bottom Line

Stay calm. Patch. Check the list. If you're exposed, fix the network and auth layers first, then audit pairings and approvals.

If you want help maintaining a tighter OpenClaw security posture over time, ClawMentor is built for exactly that.