February 2026 has been the most security-intensive month in OpenClaw’s history. With rapid adoption (190K+ GitHub stars), the project has drawn serious scrutiny from security researchers, enterprise teams, and even Microsoft. Here’s what happened, what it means, and what you should do.

The CVEs: What Was Found

CVE-2026-25253 — One-Click Remote Code Execution (CVSS 8.8)

Discovered by Mav Levin of depthfirst research, this vulnerability exploited a design flaw in the Control UI’s handling of the gatewayUrl query parameter. An attacker could craft a malicious URL that, when clicked by a user with OpenClaw running, would redirect the UI to an attacker-controlled gateway — enabling full remote code execution.

Patched in: v2026.1.29 (January 30, 2026)

Impact: Critical for anyone running the Control UI exposed to a network. Even localhost-bound instances were vulnerable via link clicks.

CVE-2026-26322 — SSRF via Gateway URL

Published February 19, this server-side request forgery flaw allowed authenticated attackers to manipulate the Gateway tool’s gatewayUrl parameter, forcing outbound WebSocket connections to arbitrary targets — internal services, cloud metadata endpoints (169.254.169.254), and more.

Patched in: v2026.2.14

CVE-2026-27008 — Arbitrary File Write via Skill Installation

Affecting versions prior to v2026.2.15, a bug in the download skill installation flow allowed arbitrary targetDir values, potentially enabling malicious file placement anywhere on the host filesystem.

Patched in: v2026.2.15

What to Do

Update immediately. If you’re running anything older than v2026.2.15, you’re exposed to at least one of these vulnerabilities. Run:

openclaw update

Or pull the latest Docker image:

docker pull openclaw/openclaw:latest

Microsoft’s Security Blog: “Running OpenClaw Safely”

On February 19, Microsoft’s security team published a detailed blog post analyzing OpenClaw’s security model. Their core argument:

OpenClaw should be treated as untrusted code execution with persistent credentials.

Key points from Microsoft:

  1. Two supply chains converge — untrusted code (skills) and untrusted instructions (external text inputs like messages, emails, web content) both flow into the same execution loop
  2. Skills are basically plugins you install from the internet — with the same trust implications as running curl | bash
  3. The agent inherits your credentials — OAuth tokens, API keys, SSH keys, and anything else on the host
  4. Moltbook and messaging integrations expand the attack surface — a single malicious post or message can reach the agent and influence its behavior
  • Run OpenClaw in a dedicated VM or container — never on your primary workstation
  • Use dedicated, non-privileged credentials — separate API keys, separate accounts
  • Implement continuous monitoring with a rebuild plan
  • Treat the deployment as ephemeral — assume compromise and design for recovery

This is strong guidance. Even if you trust the OpenClaw project itself, the skill ecosystem and messaging integrations create a broad attack surface.

The ClawHub Supply Chain Problem

The Conscia security team documented the most alarming finding: over 800 malicious skills (~20% of the ClawHub registry) were identified, primarily delivering the Atomic macOS Stealer (AMOS). This campaign, dubbed “ClawHavoc,” exploited the low-friction skill installation model.

Additionally, scanning teams (Censys, Bitsight, Hunt.io) identified 30,000+ internet-exposed OpenClaw instances, many running without authentication.

How to Protect Yourself from Malicious Skills

  1. Only install skills from trusted sources — check the author, review the code, look for community validation
  2. Review skill code before installation — skills are just code. Read them like you’d read any dependency
  3. Use allowlists — configure OpenClaw’s tool policy to restrict which skills can execute
  4. Monitor ClawHub advisories — the registry is actively cleaning up malicious packages

ClawBands: Human-in-the-Loop for OpenClaw

In response to these concerns, developer Sandro Munda released ClawBands, an open-source tool that intercepts OpenClaw tool calls and requires human approval before execution. Think of it as a firewall for your AI agent’s actions.

This is a pragmatic solution for users who want OpenClaw’s capabilities but aren’t comfortable with fully autonomous execution. It adds friction, but that friction is the point — it prevents the agent from executing actions you didn’t intend.

Enterprise Shadow AI Risk

Bitdefender telemetry confirmed OpenClaw deployments on corporate endpoints — a new category of “Shadow AI” with elevated system privileges. If you’re running OpenClaw at work:

  • Check with your security team first
  • Never use corporate credentials with a personal OpenClaw instance
  • Isolate it completely from corporate networks and data

The Big Picture

None of this means OpenClaw is fundamentally broken. The project has responded to every CVE with patches, often within days. The v2026.2.19 release included 40+ security patches. The transition to a foundation model (post Peter Steinberger’s move to OpenAI) should bring more structured security governance.

But the speed of adoption outpaced the security hardening. That’s normal for open-source projects at this growth rate — and it’s being addressed.

Your Security Checklist

  • Update to v2026.2.15+ (or latest)
  • Run in isolation — VM, container, or dedicated machine
  • Use dedicated credentials — separate API keys, not your personal ones
  • Audit installed skills — remove anything you didn’t explicitly choose
  • Don’t expose the Control UI to the internet
  • Enable authentication on the Gateway
  • Review tool policies — restrict what the agent can do
  • Consider ClawBands for human-in-the-loop approval

OpenClaw is powerful precisely because it has deep system access. That power demands respect. Stay updated, stay isolated, stay safe.

For a deeper dive into OpenClaw’s security model, see our Complete Security Guide. For the latest version, visit the official OpenClaw GitHub.