Back to Blog

OpenClaw Security Risks Every Business Should Know Before Deploying

February 14, 2026•9 min read•Team 400

OpenClaw is the fastest-growing open-source project in AI. It's also giving security teams nightmares.

With 192,000 GitHub stars and a community that doubles every few months, OpenClaw has become the default platform for businesses wanting to run autonomous AI agents. Multi-channel support, plugin architecture, and the ability to connect agents to Slack, Teams, email, and internal tools out of the box. It's genuinely impressive software.

But the security story is a different matter entirely. Over the past three months, independent researchers, enterprise security firms, and vulnerability databases have painted a picture that should make any IT leader pause before spinning up an instance on a Friday afternoon.

This post covers what's been found, what it means, and what you actually need to do if you want to run OpenClaw in a business setting.

What OpenClaw Does (Quick Version)

If you haven't come across it yet, OpenClaw is an open-source platform for building and deploying AI agents. You give it access to language models (OpenAI, Anthropic, local models), connect communication channels, and install "skills" that let agents take actions: book meetings, query databases, send emails, manage files.

The autonomous capabilities are the draw. Unlike simple chatbot wrappers, OpenClaw agents can chain actions together, maintain context across conversations, and operate across multiple channels simultaneously. For businesses, this means an AI assistant that can actually do things rather than just answer questions.

We covered the technical setup in our guide on setting up OpenClaw with Docker and channels. That post walks through the architecture. This one focuses on what can go wrong.

The Security Research: What's Been Found

CVE-2026-25253: Token Exfiltration (CVSS 8.8)

The most serious published vulnerability is CVE-2026-25253, rated 8.8 on the CVSS scale. That's "High" severity, one notch below Critical.

The flaw allows an attacker with limited access to the OpenClaw API to exfiltrate authentication tokens from the gateway service. Those tokens provide access to every connected integration: your Slack workspace, your email system, your database connections, your cloud accounts. A single compromised token can cascade into full gateway compromise.

The fix was shipped in version 0.9.14, but patching alone doesn't solve the underlying design issue. OpenClaw's gateway architecture stores integration tokens centrally, which means a breach at one point can expose everything.

42,000 Instances Exposed on the Internet

Bitsight's internet scanning research found over 42,000 OpenClaw instances directly accessible from the public internet. That number is bad enough. The worse finding: 93% of those instances had authentication bypass vulnerabilities.

Let that sink in. Ninety-three percent.

The root cause is OpenClaw's default configuration. Out of the box, the control panel binds to 0.0.0.0 (all network interfaces) on a predictable port. There's no enforced password complexity. No mandatory multi-factor authentication. No rate limiting on login attempts.

For a developer testing on a local machine, these defaults are convenient. For a business that deploys to a cloud VM and forgets to configure a firewall, they're catastrophic.

Sophos Enterprise Exploitation Advisory

Sophos published an advisory specifically targeting enterprise deployments of OpenClaw. Their research documented active exploitation patterns in the wild, including:

  • Attackers scanning for exposed OpenClaw instances using Shodan and Censys
  • Credential stuffing attacks against default admin panels
  • Abuse of the skill installation API to deploy backdoors
  • Lateral movement from compromised OpenClaw instances to internal networks

The advisory noted that OpenClaw's position as a central integration hub makes it a high-value target. Once inside, an attacker has access to every service the AI agent connects to.

System-Wide Permissions by Default

This is the one that concerns us most from an architecture perspective.

A default OpenClaw installation runs with broad system permissions. The agent process can read and write files on the host system. It can execute shell commands. It has credentials for every connected service stored in its configuration.

There's a reason for this. AI agents need permissions to be useful. An agent that can't access files or run commands can't do much. But the gap between "the agent needs some access" and "the agent has access to everything" is where risk lives.

A single prompt injection through a connected channel could instruct the agent to read sensitive files, exfiltrate data through an outbound connection, or modify system configurations. The agent doesn't know the difference between a legitimate instruction from your team and a crafted malicious prompt.

The ClawHub Problem

ClawHub is OpenClaw's community skill marketplace. Think of it like an app store for agent capabilities. Need your agent to manage Jira tickets? There's a skill for that. Query Salesforce? Skill for that too.

Snyk conducted an audit of ClawHub and the findings were stark.

36% of skills analysed had security flaws. These ranged from hardcoded credentials and insecure API calls through to arbitrary code execution vulnerabilities. More than a third of the community-contributed skills that businesses are installing into their AI agents have known security problems.

Worse still, Snyk identified a coordinated campaign that planted 341 confirmed malicious skills on ClawHub. These skills appeared legitimate, had plausible descriptions, and performed their stated function. They also exfiltrated data, installed persistence mechanisms, and opened reverse shells.

The ClawHub moderation process has improved since the Snyk report, but the fundamental trust model remains the same: skills are community-contributed, and the review process is best-effort.

We wrote a detailed breakdown of ClawHub skills and their security risks if you want the full technical analysis.

What a Secure Deployment Actually Requires

None of this means you shouldn't use OpenClaw. It means you shouldn't use it carelessly. Here's what a properly secured deployment looks like.

Network Isolation

The single most important step. Bind OpenClaw to a private network interface, not 0.0.0.0. Place it behind a reverse proxy with TLS termination. Restrict access to your internal network or VPN.

# In your OpenClaw config
server:
  host: "127.0.0.1"    # NOT 0.0.0.0
  port: 7860

If your team needs external access, put it behind an identity-aware proxy like Cloudflare Access, Tailscale, or your existing VPN. The control panel should never be directly exposed to the internet. Full stop.

Docker Sandboxing

Run OpenClaw in a Docker container with restricted permissions. Drop all Linux capabilities, mount the filesystem as read-only where possible, and limit network access to only the services the agent genuinely needs.

services:
  openclaw:
    image: openclaw/openclaw:0.9.14
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    networks:
      - internal

This won't prevent every attack, but it limits the blast radius significantly. A compromised agent in a locked-down container can do far less damage than one running with host-level access.

Credential Isolation

Never store API keys, tokens, or passwords in OpenClaw's plaintext configuration files. Use environment variables injected at runtime, or better yet, a secrets manager like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault.

# Don't do this
integrations:
  slack:
    token: "xoxb-your-actual-token-here"

# Do this instead
integrations:
  slack:
    token: "${SLACK_BOT_TOKEN}"

Rotate credentials regularly. If OpenClaw is compromised, you want to limit the window of exposure.

Skill Auditing

Before installing any ClawHub skill, review the source code. Look for:

  • Outbound network calls to unexpected domains
  • File system access beyond what the skill needs
  • Shell command execution
  • Obfuscated code or encoded strings
  • Requests for credentials or tokens

If your team doesn't have the capacity to audit skills, stick to the official maintained skills or build your own. The convenience of a community skill isn't worth the risk if nobody's reviewed what it does.

For our clients, we maintain a vetted skill allowlist as part of our OpenClaw managed service. Every skill goes through a security review before it's approved for deployment.

Audit Logging and Monitoring

OpenClaw supports logging, but it's not enabled at a useful level by default. Configure comprehensive audit logging that captures:

  • Every action the agent takes
  • Every skill invocation
  • Every API call to connected services
  • Every user interaction across all channels
  • Authentication attempts (successful and failed)

Feed these logs into your existing SIEM or monitoring stack. Set up alerts for anomalous patterns: agents accessing unusual files, spikes in API calls, skill installations outside change windows.

Authentication Hardening

Change the default admin credentials immediately. Enforce strong passwords. Enable multi-factor authentication if your deployment supports it. Implement session timeouts. Restrict admin access to named individuals, not shared accounts.

Consider integrating OpenClaw's authentication with your existing identity provider via SAML or OIDC. This gives you centralised access control and audit trails that tie back to real people.

The Gap Between "It Works" and "It's Safe for Business"

Here's the honest reality. You can get OpenClaw running in twenty minutes. Clone the repo, run Docker Compose, connect a Slack bot, install a few skills. It works. Your team is impressed. The demo goes well.

But "it works" and "it's ready for production" are separated by a significant amount of security engineering. The items listed above aren't optional extras. They're baseline requirements for any system that has access to your business communications, your customer data, and your internal tools.

We see this pattern repeatedly. A developer or team lead discovers OpenClaw, gets excited about the possibilities (fair enough, the possibilities are genuinely exciting), and spins up an instance on a cloud VM. Three months later, it's handling customer queries, managing internal workflows, and connected to half a dozen business-critical services. Nobody's reviewed the security configuration because it was "just a quick test" that became permanent infrastructure.

The open-source community is working on improving defaults. Version 0.9.14 addressed some of the worst issues. But open-source projects optimise for developer experience and adoption, not enterprise security posture. That's not a criticism. It's a structural reality of how open-source works.

Our guide on running OpenClaw in production covers the full operational picture beyond security: monitoring, scaling, backup, and maintenance.

Getting Started the Right Way

If you're evaluating OpenClaw for your business, here's our recommendation.

Start with a threat model. What data will the agent access? What actions can it take? What's the worst case if it's compromised? Answer these questions before you write any configuration.

Run a proof of concept in isolation. Use a dedicated environment with test data. Don't connect production services during evaluation. Get comfortable with the platform's behaviour before giving it real access.

Invest in the security configuration. Budget time for network isolation, container hardening, credential management, and monitoring. If your team doesn't have experience with these areas, get help.

Audit before you trust. Every skill, every integration, every permission. Verify what OpenClaw can access and confirm it matches what you intended.

If you'd rather skip the security engineering and get straight to a production-ready setup, we offer managed OpenClaw for business. We handle the infrastructure, security hardening, skill vetting, monitoring, and ongoing maintenance. You focus on building the agent workflows that actually help your team.

For businesses that want to run it themselves, we're happy to do a security review of your existing deployment or help architect a new one. The technology is sound. It just needs to be deployed with the same care you'd give any other system that touches your critical business data.

OpenClaw is going to be a big part of how businesses use AI agents. Getting the security right from day one is a lot cheaper than cleaning up a breach later.