Is my OpenClaw install exposed?

OpenClaw before 2026.5.18? Audit shell-wrapper approvals.

CVE-2026-53822 is a sharp reminder that command approval is only useful when the command shape checked is the command shape that runs. GitHub's advisory says affected OpenClaw versions could approve one shell-wrapper argv shape and rebuild another for execution, bypassing the allowlist in configurations where that path was enabled and reachable. Treat this as a narrow but high-leverage upgrade/audit: patch to 2026.5.18+, require explicit approval for wrapper-heavy commands until patched, and prove your exec policy with a small negative test before unattended agents resume host execution.

Provider key in a workspace `.env`? Move it before agents run.

OpenClaw's environment docs now draw a useful trust boundary: workspace `.env` files are lower-trust and provider credentials loaded only from there are ignored. That is good hardening, but it can look like a broken model route if you do not know where the Gateway process actually reads keys. Treat the fix as both reliability and security work: move provider keys into a trusted OpenClaw env/secret source, remove plaintext residue from agent-readable files, then prove one tiny provider call before unattended work resumes.

Installing skills or plugins? Add an install-policy gate.

OpenClaw 2026.6.5 added `security.installPolicy`, a local command hook that can approve or block skill and plugin installs after source material is staged and before install/update continues. Use it when ClawHub, uploaded archives, Git/local skills, dependency installers, or plugins can change your agent surface. The operator rule is simple: stage first, inspect locally, fail closed if the policy command is missing, then smoke-test before trusting the new tool path.

OpenClaw allowlists: use stable sender IDs, not names.

A recent OpenClaw advisory is a good reminder for anyone letting chat messages trigger elevated tools: mutable usernames and display-style metadata can drift away from the stable sender you meant to trust. For Telegram, the verified GitHub advisory calls out mutable usernames directly; for other channels, treat the same class as an audit pattern, not a blanket claim. Use stable platform IDs where possible, keep name matching opt-in and documented, and smoke-test the channel before resuming unattended work.

Gateway still using `auth=none`? Upgrade and fail closed.

OpenClaw 2026.1.29 removed Gateway auth mode `none`: the Gateway now expects token/password auth, while trusted Tailscale Serve identity remains a separate allowed path. The same release notes and changelog also call out a fail-closed boundary: loopback requests with a non-local Host should be treated as remote unless trusted proxy headers prove otherwise. Treat this as an exposure audit, not just a config typo. Snapshot first, replace `auth=none`, verify proxy/Tailscale assumptions, then smoke-test both the unauthorized path and the intended CLI/agent path before unattended work resumes.

OpenClaw before 2026.4.22? Audit sandbox and MCP exposure.

A fresh X security cluster is useful because it points to official records, not just chatter. NVD and GitHub advisories list four OpenClaw issues fixed in 2026.4.22: OpenShell filesystem write/read symlink-race escapes, shell expansion hidden in unquoted heredocs, and spoofable loopback MCP owner context. If an older install was exposed to shared users, tunnels, reverse proxies, or untrusted prompts/plugins, treat this as an upgrade-and-exposure review before trusting agent work again.

OpenClaw before 2026.4.20? Lock down config mutation.

CVE-2026-45001 reports a guard bypass in OpenClaw's agent-facing gateway `config.patch` and `config.apply` endpoints before 2026.4.20. The risk is not just a broken setting: a prompt-injected model with owner-only gateway-tool access could persist changes to operator-trusted controls such as sandbox policy, plugin enablement, gateway auth/TLS, hook routing, MCP server configuration, SSRF policy, and filesystem hardening.

Self-hosted OpenClaw older than 2026.4.10? Audit it now.

Recent CVE chatter is worth acting on if you expose OpenClaw beyond your laptop. GitHub, NVD, and CVE records now point to several fixed-before-2026.4.10 issues: sandbox noVNC helper-route authentication bypass, Nostr plugin profile-route access control, sandbox browser CDP relay binding too broadly to `0.0.0.0`, and external hook metadata being enqueued as trusted system events. Treat this as an upgrade-and-exposure audit, not a panic reinstall.

Installing random ClawHub skills? Quarantine first.

Acronis TRU reports an active AI supply-chain campaign that abused Hugging Face and ClawHub/OpenClaw, including 575+ malicious OpenClaw skills across 13 developer accounts. Treat third-party skills like code that can reach your workspace: useful, but not something to install blind in the same profile that holds credentials, production repos, or agent memory.

Giving agents real API keys? Broker them instead.

Infisical's Agent Vault launch is a useful reminder, not a magic shield: agents like OpenClaw and Hermes should not need to hold raw API keys in their context, env, or readable config. A broker/proxy can keep the real credential outside the agent and attach it only on allowed outbound requests. If your current setup already exposed provider, GitHub, Stripe, database, or bot tokens to agents, treat the migration as a controlled auth-change: snapshot first, rotate carefully, and smoke-test before unattended work resumes.

Exposed openclaw.json? Rotate before agents run.

A field report warned that exposed OpenClaw config files can become a model-credit-drain path. The exact incident still needs independent confirmation, but the risk is real: OpenClaw config can contain provider keys, tokens, app secrets, and gateway settings, and a closed GitHub issue showed how raw config exposure can leak plaintext credentials through tool surfaces.