Security Upgrade Hardening

Post-upgrade security checks for OpenClaw operators

Page scope (security-hardening niche): This page focuses on security posture after upgrades, not general installation or release history. For migration steps use Upgrading / Migrating; for chronological release notes use Releases.

Core hardening checklist

  1. Run openclaw doctor --fix and then openclaw doctor.
  2. Confirm gateway auth is enabled for non-loopback exposure.
  3. Re-check trusted-proxy behavior and token setup after upgrades.
  4. Verify DM pairing policy and allowlists for every channel you use.
  5. Review exec policy (security, ask, fallbacks) and approvals file health.
  6. Restart gateway and validate logs are clean for auth, pairing, and exec warnings.

Security-focused commands

Post-upgrade commands
openclaw doctor --fix
openclaw doctor
openclaw security audit --deep
openclaw gateway restart

When reporting issues, include openclaw --version and relevant command output.

What to re-check after recent releases

  • v2026.4.10: broad browser/sandbox SSRF and navigation hardening; exec preflight and host env denylists; plugin install scanning and WebSocket frame limits—re-run openclaw security audit --deep after upgrade.
  • v2026.4.9: browser SSRF checks after in-page navigations; untrusted workspace .env restrictions; sanitized node exec event text; dependency audit bumps—pair with openclaw doctor and openclaw security audit --deep.
  • v2026.4.5: security-related tightening for allowlists, hook failures, SSRF redirects, and plugin tool allowlists—re-run openclaw security audit --deep after upgrade.
  • v2026.4.2: exec defaults and approvals normalization behavior can change effective policy if your approvals file contains invalid enums.
  • v2026.3.31: stricter trust and pairing boundaries for gateway/node surfaces; node commands remain pairing-gated.

For exact migration items, use Upgrading / Migrating.

Related