OpenClaw Security: Threats, CVEs, and a 7-Step Hardening Guide
The complete OpenClaw security reference — what the agent can access on a local machine, the real CVEs that exposed 40,000+ instances in 2026, and a 7-step defense-in-depth hardening checklist.
March 31, 2026·14 min read
40K+
exposed instances (2026)
3
critical CVEs in 2026
7
hardening steps
TL;DR
Three critical CVEs in 2026 — CVE-2026-25253, CVE-2026-25593, and CVE-2026-32915 — left 40,000+ self-hosted OpenClaw instances vulnerable to remote code execution. Running OpenClaw locally gives the agent unrestricted access to your files, credentials, and browser sessions, with no isolation, egress control, or automatic patching. This guide covers the threat landscape (rogue behavior, malicious skills, prompt injection, data leakage, no kill switch), a local-vs-sandboxed comparison, and seven layers of defense — network isolation, secrets management, RBAC, container security, audit logging, TLS/mTLS, and dependency scanning. Apply in order of impact, or use a managed platform like Rapid Claw that ships with most of these controls built in.
Want these controls out of the box?
Try Rapid Claw — 5 msgs free, then $29/mOpenClaw is an open-source AI agent with over 247,000 GitHub stars↗ that can see your screen, control your keyboard, and access every application on your machine. That power is also its greatest security liability. In 2026, three critical CVEs — CVE-2026-25253 (one-click RCE in the webhook handler), CVE-2026-25593 (command injection via shell metacharacters), and CVE-2026-32915 (RCE in the MCP relay) — left over 40,000 self-hosted instances↗ exposed to full system compromise.
Malwarebytes, SecurityScorecard, and Microsoft Security all reached the same conclusion: OpenClaw running with production credentials belongs in an isolated, sandboxed environment with egress controls, automated patching, and centralised audit logging.
This guide covers the complete OpenClaw security picture — what the agent can actually access on a local machine, the five most common threat vectors, a local-vs-sandboxed comparison, and seven concrete hardening layers you can apply today. Whether you’re running OpenClaw on a single VPS or across a Kubernetes cluster, the steps below will materially reduce your attack surface.
What OpenClaw Can Access on a Local Machine
When you install OpenClaw locally, you’re giving an AI agent the same level of access as a person sitting at your desk. Specifically, it can:
- See your entire screen — including passwords typed into login forms, bank account pages, private messages, and health records.
- Read and modify any file — documents, browser history, SSH keys, saved passwords in config files, cryptocurrency wallets, tax returns.
- Execute terminal commands — install software, modify system settings, access your network, or connect to external servers.
- Browse the web as you — with access to your logged-in sessions, cookies, and saved passwords.
- Access email and messaging — if Gmail, Slack, or WhatsApp is open, the agent can read and send messages on your behalf.
The Five Real Threats to an OpenClaw Deployment
Hardening is only useful if you know what you’re defending against. These are the five threat categories researchers and operators see most often:
1. Rogue agent behavior
AI models hallucinate or misinterpret instructions. When a chatbot hallucinates, you get wrong text. When a computer-use agent hallucinates, it might delete the wrong folder, send the wrong email, or run a destructive command. On a local machine, there’s no sandbox to contain the damage.
2. Malicious community skills
OpenClaw supports community-built skills that extend the agent. Anyone can publish one and not all are audited. A malicious skill can exfiltrate data, install a backdoor, or grant remote access. See the ClawdHub skills guide for safe-use practices.
3. Prompt injection attacks
When OpenClaw reads a webpage, email, or document, it can encounter hidden instructions designed to hijack the agent. CVE-2026-25593 was exactly this attack surface at scale — crafted payloads in documents and web pages caused agents to execute attacker-controlled shell commands. See our prompt injection defense guide for mitigations.
4. Data leakage to AI providers
Every screenshot and action OpenClaw takes is sent to an LLM provider (Anthropic, OpenAI, etc.) for processing. If you’re working with NDAs, financial data, medical records, or trade secrets, that data is flowing to a third party. Most users don’t realise this at install time.
5. No kill switch when unattended
A 24/7 agent running overnight is the point — but if it goes off-script at 3am (clicking the wrong things, sending the wrong messages, running destructive commands), there’s nobody watching. Without audit logging and egress controls, you find out in the morning.
The Architectural Problem with Local Installation
Each of the 2026 CVEs shares a common root cause: OpenClaw running locally inherits the full privilege context of its host machine, with no isolation layer between the agent’s operations and the broader system.
No process isolation.
The agent runs as a native process with the same permissions as the logged-in user. A compromised agent is a compromised user account.
No egress controls.
By default, OpenClaw can make outbound connections to any internet endpoint. There is no mechanism to restrict where data can be sent.
Credential co-location.
The host machine stores the credentials the agent has been given access to. Compromising the agent means accessing those credentials directly.
No audit trail.
A locally-installed agent leaves no centralised log of its actions. If something goes wrong, reconstruction is often impossible.
Manual update dependency.
Applying patches requires the user to manually pull the latest version. The average self-hosted instance was running 47 days behind at time of migration to Rapid Claw.
Local vs Sandboxed Hosting: The Security Delta
Local Installation
Process Isolation
None
Egress Controls
None
Credential Security
Co-located with agent
Audit Logging
Manual/Missing
Security Patching
Manual update required
Rapid Claw Sandboxed
Process Isolation
Full container isolation
Egress Controls
Restricted by default
Credential Security
AES-256 encrypted, isolated
Audit Logging
Centralised, immutable
Security Patching
Automatic within 4 hrs
Rapid Claw applied patches to all customer instances within 3 hours of the CVE-2026-25253 and CVE-2026-25593 disclosures. No user action required. For the detailed infrastructure layers that make this possible, keep reading — the seven hardening steps below are exactly what a well-run managed platform provides by default.
The 7-Step Hardening Checklist
Below are the seven infrastructure layers that contain the blast radius of any vulnerability — known or unknown. Apply in order of impact (see the priority order below), or use a managed platform that ships these controls by default.
In this guide
Network Isolation
Why this matters: An OpenClaw agent with unrestricted network access can reach any endpoint on the internet — and if compromised, so can an attacker. CVE-2026-32915 was exploited through open egress to exfiltrate data via DNS tunneling.
Deploy in an isolated network segment
Run your OpenClaw instance inside a dedicated VPC or VLAN. Do not share the network segment with other production workloads. In Kubernetes, use a dedicated namespace with strict NetworkPolicy.
Default-deny egress
Block all outbound traffic by default. Whitelist only the specific endpoints your agent needs: LLM API endpoints (api.anthropic.com, api.openai.com), your application backend, and the secrets manager. Use Kubernetes NetworkPolicy or host-level iptables rules.
Restrict DNS resolution
Point the agent to an internal DNS resolver that only resolves whitelisted domains. DNS is a common exfiltration channel — blocking arbitrary DNS queries prevents data from leaking through subdomain encoding.
Log all network flows
Enable VPC flow logs or equivalent. Every connection attempt — successful or blocked — should be recorded. Set up alerts for connection attempts to unexpected destinations.
Secrets Management
Why this matters: Hardcoded credentials are the most common root cause of agent compromise. If an attacker gains code execution through a vulnerability like CVE-2026-32915, every secret baked into the environment or config file is immediately exposed.
Use a dedicated secrets manager
Store all credentials in HashiCorp Vault, AWS Secrets Manager, or equivalent. Never store secrets in environment variables baked into container images, .env files committed to version control, or application configuration files.
Inject secrets at runtime only
Mount secrets as ephemeral volumes or fetch them via API at startup. The container image itself should contain zero credentials. Run `strings` on your container image to verify — if any API key appears, your secrets pipeline is broken.
Rotate credentials automatically
Set up automated rotation: API keys every 30 days, database passwords every 90 days, TLS certificates before expiry. Revoke old credentials immediately after rotation. If a key is compromised, the rotation window is your exposure window.
Scope every credential to minimum permissions
Each API key should grant access to only the specific endpoints the agent calls. Database credentials should be scoped to SELECT on the required tables — not superuser. Audit credential scope quarterly.
Role-Based Access Control (RBAC)
Why this matters: Without RBAC, every user and service that can reach your OpenClaw instance has the same level of access. A junior developer should not be able to modify agent configurations that control production data access.
Define roles with explicit permissions
Create at minimum three roles: Admin (full configuration access), Operator (start/stop agents, view logs, no config changes), and Viewer (read-only dashboard access). Map each team member to the most restrictive role that lets them do their job.
Enforce RBAC at the API layer
Every API endpoint should check the caller's role before executing. Do not rely on frontend-only access control — use middleware or gateway-level authorization. Reject unauthorized requests with 403, not 200 with an empty response.
Separate agent permissions from human permissions
The OpenClaw agent runtime should have its own service account with permissions scoped to its actual needs. Agents should never inherit a human user's session or credentials. Use separate service accounts for each agent if running multiple.
Audit role assignments quarterly
Review who has what access every 90 days. Remove access for people who have changed roles or left the team. Check for role drift — users who were granted temporary elevated access and never downgraded.
Container Security
Why this matters: Containers are the primary isolation boundary for OpenClaw deployments. A misconfigured container — running as root, with a writable filesystem, or with host-level capabilities — eliminates most of the security benefits containerization provides.
Run as non-root with a read-only filesystem
Set `USER 1000` in your Dockerfile. Mount the root filesystem as read-only (`readOnlyRootFilesystem: true` in Kubernetes). Use tmpfs mounts for directories that need write access (e.g., /tmp). This prevents an attacker from modifying binaries or installing backdoors.
Drop all capabilities, add back only what's needed
In your container security context, set `drop: [ALL]` and then add back only required capabilities. Most OpenClaw deployments need zero additional capabilities. Never grant SYS_ADMIN, NET_RAW, or SYS_PTRACE.
Use a minimal base image
Build from distroless or Alpine images, not ubuntu:latest. Fewer packages mean fewer CVEs. Your production container should not include curl, wget, apt, or a shell. If you need debugging tools, use ephemeral debug containers in Kubernetes.
Enable runtime sandboxing
Use gVisor (runsc) or Kata Containers for an additional isolation layer beyond standard Linux containers. gVisor intercepts system calls, preventing the container from directly interacting with the host kernel. This blocks kernel exploits that would escape a standard container.
Audit Logging
Why this matters: Without audit logs, you cannot detect compromise, investigate incidents, or prove compliance. After CVE-2026-32915, organizations without logging had no way to determine whether their agents had been exploited or what data may have been accessed.
Log every agent action to an immutable store
Capture every API call, tool invocation, file access, and database query. Ship logs in real-time to a write-once store (S3 with Object Lock, CloudWatch, Datadog). The agent process must not be able to modify or delete its own logs.
Include context in every log entry
Each log entry should contain: timestamp (UTC), agent ID, action type, target resource, request payload hash, response status, and source IP. Without this context, logs become noise instead of signal during incident response.
Set up real-time alerting
Alert on: failed authentication attempts (>3 in 5 minutes), connections to new external IPs, privilege escalation attempts, abnormal API call volume (>2x baseline), and access to sensitive resources outside business hours. Use your SIEM or a tool like Falco for runtime alerting.
Test your incident response with log reconstruction
Quarterly, simulate a compromise: pick a random 1-hour window and reconstruct every action the agent took. If you cannot build a complete timeline from your logs, your logging pipeline has gaps. Fix them before a real incident forces you to find out.
TLS & mTLS Everywhere
Why this matters: Unencrypted traffic between your agent and other services means anyone on the network path can read credentials, prompts, and responses. Mutual TLS (mTLS) goes further by ensuring both sides of every connection prove their identity — preventing rogue services from impersonating legitimate endpoints.
Enforce TLS 1.3 on all connections
Disable TLS 1.0, 1.1, and 1.2 where possible. TLS 1.3 eliminates known protocol weaknesses and reduces handshake latency. Configure your agent's HTTP client to reject connections that negotiate below TLS 1.3.
Deploy mTLS for inter-service communication
Use a service mesh (Istio, Linkerd) or manual certificate management to require mutual authentication between your OpenClaw agent and every backend service. Both sides present certificates signed by your internal CA. Unsigned or expired certificates should terminate the connection immediately.
Automate certificate lifecycle
Use cert-manager (Kubernetes) or ACME (Let's Encrypt) to issue and renew certificates automatically. Set certificate lifetimes to 90 days maximum. Monitor for expiring certificates — an expired cert can cause a hard outage or silently fall back to unencrypted traffic.
Pin certificates for critical connections
For connections to LLM provider APIs and your secrets manager, implement certificate pinning. This prevents man-in-the-middle attacks even if a CA is compromised. Update pins as part of your certificate rotation process.
Dependency Scanning
Why this matters: OpenClaw has a deep dependency tree. A vulnerability in any transitive dependency — not just OpenClaw itself — can compromise your deployment. CVE-2026-32915 was discovered in a component most operators didn't know they were running.
Scan on every build, not just periodically
Integrate dependency scanning into your CI/CD pipeline. Every commit that changes dependencies should trigger a scan. Use tools like Snyk, Trivy, or Grype to check both application dependencies (npm audit, pip audit) and container base image vulnerabilities.
Block builds with critical/high CVEs
Configure your CI/CD pipeline to fail if a critical or high-severity CVE is detected. Do not allow manual overrides without a documented exception and a remediation deadline. Track exceptions in a security backlog and review them weekly.
Monitor for new CVEs in production dependencies
Scanning at build time catches known issues. But new CVEs are published daily. Use a continuous monitoring service (Snyk Monitor, GitHub Dependabot, or your scanner's watch mode) to alert you when a new vulnerability affects a dependency already running in production.
Generate and maintain an SBOM
Create a Software Bill of Materials (SBOM) for every deployment. When a new CVE drops — like CVE-2026-32915 — you need to know within minutes whether you're affected. An SBOM lets you query "do we run this component?" without digging through container layers.
Don’t want to manage all seven layers yourself?
Rapid Claw ships with network isolation, container hardening, audit logging, mTLS, and dependency scanning as baseline. You configure RBAC and credentials — we handle the infrastructure.
Try Rapid Claw — 5 free msgs, then $29/mWhere to Start: Priority Order
If you can’t do everything at once, apply these steps in order of impact:
Network Isolation + Secrets Management
Blocks the two most common attack vectors: data exfiltration and credential theft.
Container Security + RBAC
Limits what an attacker can do if they get in. Non-root containers and least-privilege access shrink the blast radius.
Audit Logging
Without logs, you cannot detect compromise or investigate incidents. Deploy early so you have baseline data.
TLS/mTLS + Dependency Scanning
Encrypts everything in transit and catches known vulnerabilities before they reach production.
If You Must Run OpenClaw Locally
We respect the self-hosting community. If you’re going to run OpenClaw on your own machine — rather than on a hardened VPS or managed platform — here’s the minimum you should do:
- 1Run it on a separate user account — not your primary account with all your personal files and browser sessions.
- 2Use a virtual machine or Docker container — this provides filesystem and network isolation.
- 3Set strict API spending limits — a runaway agent can burn hundreds of dollars in API costs in hours.
- 4Log out of sensitive accounts — close your bank, email, and social media sessions before letting the agent run unsupervised.
- 5Only install verified community skills — read the source of any plugin before enabling it.
- 6Never run it with admin/root privileges — this limits the potential damage of any rogue behavior.
- 7Patch within 48 hours of any CVE — and assume any credentials exposed prior to patching are compromised.
Further Reading
This guide focuses on infrastructure-level hardening. For complementary perspectives on AI agent security:
- Prompt Injection Defense for Production Agents — mitigations for the attack class behind CVE-2026-25593
- AI Agent Firewall Setup — egress controls and network segmentation in detail
- AI Agent Observability — audit logging, metrics, and alerting patterns
- Security & Privacy at Rapid Claw — how the managed platform addresses these concerns by default
- AI Agent Deployment Checklist — a downloadable checklist covering pre-launch security, configuration, and go-live readiness
Sources
- SecurityScorecard — CVE-2026-25253 / CVE-2026-25593 exposure research, March 2026
- Malwarebytes Blog — OpenClaw local installation security analysis
- Microsoft Security Response Center — OpenClaw safe deployment advisory
- OpenClaw GitHub repository — feature documentation, star count, and release history
Frequently Asked Questions
Related Articles
Hardened by default
Skip the hardening marathon.
Rapid Claw ships with network isolation, container sandboxing, mTLS, audit logging, and automated dependency scanning as baseline. You own your data and credentials — we handle the infrastructure security.
AES-256 encryption · Automatic CVE patching · No standing staff access