TL;DR for the impatient: CVE-2026-33579 let unauthenticated attackers approve their own pairing requests on exposed OpenClaw instances. If your gateway was publicly accessible before v2026.3.28, run the log checks below. If you find anything suspicious, treat it as a full compromise.

What Actually Happened

The vulnerability was in the /pair approve endpoint. It failed to verify that the approving party was a legitimate admin — meaning anyone who could reach your OpenClaw gateway could approve their own device pairing, gain agent-level access, and execute tools on your behalf.

The patch commit (e403decb in v2026.3.28) added callerScopes enforcement so requested scopes must be a subset of the caller's own scopes. But the patch only helps if you've updated. And it only prevents new exploits — it doesn't tell you if you were hit before the patch.

The window of exposure: anyone running an unpatched, publicly-accessible OpenClaw between the vulnerability's discovery and v2026.3.28 (March 28). That's potentially days or weeks depending on when you last updated.

Who's most at risk: Anyone whose OpenClaw gateway was bound to 0.0.0.0 (all interfaces) without a firewall rule blocking port 3000 or without an auth token. This is unfortunately the default setup for most quick-start installs.

Step 1: Check If You Were Exposed

Before checking for compromise, confirm whether your gateway was even reachable. Run this:

# Check your current gateway binding
grep -i "bind\|host\|port" ~/.openclaw/openclaw.json 2>/dev/null || cat ~/.openclaw/openclaw.json | grep -A2 "gateway"

# Check if port 3000 is/was publicly accessible
sudo ss -tlnp | grep 3000
# If this shows 0.0.0.0:3000 — your gateway was publicly exposed

If your gateway was bound to 127.0.0.1 only and behind a reverse proxy, your exposure was minimal. If it was on 0.0.0.0 — keep reading.

Step 2: Check Your Pairing Logs

The exploit requires a /pair approve call. That leaves a trace in logs:

# Check OpenClaw logs for suspicious pairing activity
grep -i "pair\|approve\|pairing" ~/.openclaw/logs/*.log 2>/dev/null | tail -50

# On systemd installs:
journalctl -u openclaw --since "2026-03-01" | grep -i "pair\|approve" | tail -50

# Look for IPs you don't recognize
grep -i "pair" ~/.openclaw/logs/*.log 2>/dev/null | grep -v "127.0.0.1\|::1" | tail -30

You're looking for pairing approval events from IP addresses you don't recognize — especially from ranges you've never connected from.

Step 3: Check Connected Devices

# List all paired devices
cat ~/.openclaw/devices.json 2>/dev/null

# Or via CLI if running:
openclaw devices list

Look for any device entries you don't recognize. Unknown device names, unfamiliar timestamps, or entries with no label are all worth investigating.

Step 4: Check Tool Execution Logs

If an attacker gained access, they could execute tools — file reads, web requests, exec commands. Check for suspicious activity:

# Check recent tool calls in session logs
find ~/.openclaw/workspace -name "*.md" -newer ~/.openclaw/openclaw.json -type f | head -20

# Check git log for unexpected changes
cd ~/.openclaw/workspace && git log --oneline --since="2026-03-01" | head -30

# Check for unexpected files
ls -la ~/.openclaw/workspace/
ls -la ~/.ssh/  # Was SSH access touched?

Step 5: Check API Usage

An attacker using your agent would burn API credits. Check your provider dashboards:

A sudden usage spike you can't explain — especially during hours when you weren't using the agent — is a strong indicator of unauthorized access.

Indicators of Compromise (IoCs)

Any of these should be treated as a confirmed compromise:

If You Find Evidence of Compromise

Step 1

Revoke all API keys immediately

Go to Anthropic and OpenAI dashboards — rotate every key that was in your openclaw.json. Do this before anything else.

Step 2

Remove all unknown paired devices

Edit ~/.openclaw/devices.json and remove any device you don't recognize. Or wipe it entirely and re-pair your own devices.

Step 3

Review your workspace for backdoors

Check your SOUL.md, AGENTS.md, and any scripts in your workspace. An attacker could have modified your agent's behavior. Run git diff HEAD~10 to see recent changes.

Step 4

Lock down the gateway now

If you haven't already: bind to 127.0.0.1, add an auth token, set up a reverse proxy, restrict firewall to ports 80/443 only. See our setup checklist for the full lockdown procedure.

Step 5

Consider a full server audit

If your OpenClaw had exec tool access and an attacker ran arbitrary commands, your entire server may need to be treated as compromised — not just OpenClaw. Check for new cron jobs (crontab -l), new SSH keys, and unexpected processes (ps aux).

If You're Clean — Stay That Way

If your checks come back clean, lock things down so this can't happen again:

  1. Update to v2026.3.28 or later if you haven't
  2. Bind gateway to 127.0.0.1 — not 0.0.0.0
  3. Set a strong auth token in openclaw.json
  4. Put nginx in front with HTTPS
  5. Subscribe to OpenClaw GitHub releases for CVE alerts

If you're not confident running through these checks yourself — or you found something and aren't sure what it means — book a call. ClawReady does security audits ($49) that cover exactly this: we review your logs, config, and workspace and tell you what we find.