OpenClaw security vulnerabilities we found and fixed

OpenClaw is the open-source AI agent that's been all over tech Twitter. It lets you control your computer with natural language: read files, send emails, browse the web, run terminal commands. It went from zero to 145,000 GitHub stars in a few weeks.

It runs with full system access. It's also moving fast. Peter Steinberger made 6,600 commits in January, much of it AI-generated. That kind of velocity is impressive, but it makes thorough security review really hard. Our guide to AI code security covers the flaws AI coding tools introduce and how to catch them in review.

We ran a codebase scan on it using cubic. Our agents found critical, exploitable vulnerabilities. We built fixes for the 4 most severe and submitted PRs. The OpenClaw team merged all of them within hours.

Here's what we found, why it matters, and how we fixed it.

How We Found Them

On February 2, 2026, we ran a cubic codebase scan on the OpenClaw repo. Thousands of AI agents analyzed the codebase in parallel, tracing data flows across files and checking for exploitable vulnerabilities.

We evaluated each finding against OpenClaw's threat model. OpenClaw intentionally runs with significant system access, and users accept that tradeoff. But several of these vulnerabilities violated even that permissive boundary. These weren't configuration mistakes. They were core security flaws in correctly configured installations.

We prioritized the 4 with the highest real-world impact, built fixes, and submitted pull requests.

The 4 Vulnerabilities We Fixed

1. Gateway Credential Exfiltration via URL Override

A chat message can steal your gateway admin credentials. That's the short version.

OpenClaw's gateway is the central server that manages your AI agent. It handles tool execution, conversation history, and connections to services like WhatsApp and voice. Your gateway credentials give full control over your entire OpenClaw installation.

The gateway client automatically attaches locally configured admin credentials (from environment variables or config files) when connecting to a gateway URL. The problem: when the gatewayUrl parameter is overridden via tool arguments, the client still falls back to those local credentials. A chat message or prompt injection can point the client to wss://attacker.example/ws and receive real gateway tokens.

With stolen gateway credentials, an attacker gets full control over the OpenClaw installation: tool execution, conversation history, and all connected services.

A similar issue in the Control UI was patched as CVE-2026-25253 in January. Our scan found the same class of vulnerability in a different code path: the gateway client's tool interface.

The fix: When a URL override is provided, require explicit credentials. Don't fall back to local config.

PRs: Original #8113 | Merged #9179

2. OpenClaw Instance Hijack via WhatsApp Login

Any contact on your WhatsApp allowlist can take full control of your OpenClaw instance. Even if they fail, your gateway goes down.

OpenClaw lets you add contacts to an allowlist so they can message your bot through WhatsApp. The whatsapp_login tool generates a WhatsApp Web pairing QR code. This sensitive tool was available to all allowed senders, not just the owner.

When whatsapp_login is triggered while the gateway is running, it creates a second WhatsApp connection using the same credentials. WhatsApp detects the conflict and immediately disconnects the existing session. The attacker scans the new QR code and takes control of OpenClaw's WhatsApp channel.

The original owner doesn't just lose access. Their OpenClaw instance is actively hijacked. And even if the attacker fails to scan the QR in time, simply triggering the tool causes a denial-of-service by disconnecting the gateway.

The fix: Gate whatsapp_login to owner-only access. We added an explicit owner allowlist for sensitive operations and threaded senderIsOwner through the agent pipeline.

PRs: Original #8768 | Merged #9202

3. Voice Allowlist Bypass

Block your caller ID and you bypass the voice allowlist entirely.

OpenClaw's voice call feature includes an allowlist to restrict who can call your bot. A logic bug made this control completely ineffective.

The code used suffix matching instead of exact matching and didn't handle anonymous callers correctly. When a caller blocks their ID, Twilio returns "anonymous". Stripping non-digits yields an empty string. Since every string ends with an empty string, endsWith("") is always true. Anyone could bypass the voice allowlist by simply blocking their caller ID.

The fix: Reject calls with missing caller ID and use exact matching.

PRs: Original #8104 | Merged #9188

4. Sandbox Bypass via Media Parameter

Even with sandboxing enabled, an attacker can read any file on your system through the media parameter.

OpenClaw has a sandboxing feature that restricts file access to a specific directory. The message tool validates path and filePath parameters against the sandbox root. But it didn't validate the media parameter. A user could read arbitrary files by passing a file:// URL through media, bypassing the sandbox entirely.

The fix: Apply the same sandbox validation to the media parameter, with appropriate handling for HTTP URLs (allowed), data URLs (disallowed for media), file:// URLs (validated), and local paths (validated).

PRs: Original #8780 | Merged #9182

To catch this class of bug before it merges, cubic's AI code review has a Node.js path traversal agent that flags file paths built from untrusted input without a base-directory check.

Why This Matters

None of these bugs are obvious. The voice allowlist bypass is a good example: suffix-matching logic that handles every normal input correctly but breaks on one edge case (anonymous callers). You could read that code in a PR review and approve it without a second thought.

That's the challenge with AI-generated code at this velocity. The volume of new code outpaces what any team can manually review. These bugs shipped in a project with 145,000 stars and thousands of contributors watching.

Our agents found them in hours because they could trace data flows and edge cases across the entire codebase in parallel. That's not a replacement for human review. It's a way to keep up.

In OWASP Top 10 2025 terms, the voice allowlist bypass is an authentication failure (A07), and the WhatsApp login and media sandbox bugs are broken access control (A01). For AI-written code in general, Bug Bench's security and privacy ranking compares AI models by their rate of those bugs in the code cubic reviews.

Want to Find What's Hiding in Your Codebase?

Most of these weren't classic security bugs. They were business logic errors: a suffix match that should have been exact, a parameter that got skipped in validation, a credential fallback that was too permissive. The kind of bugs that look reasonable in isolation but break down at the edges.

cubic codebase scans find these. Not just security vulnerabilities, but logic bugs, missed edge cases, and broken assumptions across your entire codebase.

Book a demo to run one on your repository.

Disclosure Timeline

February 2, 2026 - Ran codebase scan on OpenClaw repository

February 2, 2026 - Identified 4 critical security vulnerabilities

February 3, 2026 - Submitted pull requests with fixes for all vulnerabilities

February 4, 2026 12:34 PM UTC - Contacted Peter Steinberger (OpenClaw founder) with detailed vulnerability report

February 4, 2026 10:13 PM UTC - OpenClaw team acknowledged receipt and began review

February 4, 2026 23:59 UTC - PR #9179 (Gateway Credential Exfiltration) merged

February 5, 2026 00:11 UTC - PR #9182 (Sandbox Bypass) merged

February 5, 2026 00:23 UTC - PR #9188 (Voice Allowlist Bypass) merged

February 5, 2026 00:49 UTC - PR #9202 (WhatsApp Hijack) merged

February 5, 2026 - Public disclosure after verification of fixes

All fixes referenced in this post have been merged into the OpenClaw main repository. Thanks to the OpenClaw maintainers for their responsiveness in reviewing and merging these security improvements.

FAQ

Is OpenClaw safe to use?

OpenClaw's security docs say its conservative defaults keep you in good shape: on a regular host install the Gateway binds to loopback, most chat channels answer an unknown sender with a pairing code, and group access is allowlisted. Container images are the exception: they bind to an exposed interface by default, so pair them with auth. The docs treat one gateway as one trust boundary, so users who don't trust each other need separate gateways and credentials, and a public agent should run sandboxed with no filesystem or shell tools. The four flaws in this post affected correctly configured installs and were fixed in February 2026, so run a current release.

What is CVE-2026-25253?

It is a high-severity OpenClaw flaw (CVSS 3.1 score 8.8) in versions before 2026.1.29. The Control UI took a gatewayUrl value from the query string and connected to it without prompting, sending the stored gateway token, which OpenClaw's advisory describes as a 1-click RCE through token exfiltration. The fix in 2026.1.29 makes the user confirm a new gateway URL. The first flaw in this post is the same class of bug in the gateway client's tool interface.

Where can I find the latest OpenClaw security vulnerabilities?

OpenClaw publishes them as security advisories on its GitHub repository, and each one lists the affected and patched versions. Advisories that get a CVE ID, such as CVE-2026-25253, also appear in NVD. Compare the patched versions with the release you run.

How do I check my OpenClaw setup for security problems?

Run openclaw security audit after any config change and before you expose a network surface; among other things, it checks whether strangers can trigger the bot through your DM and group policies. Add --deep to attempt a live Gateway check. The --fix flag applies a narrow set of safe fixes: it switches open group policies to allowlists and tightens permissions on state and config files, as the audit docs explain.