Between March 19 and March 22, 2026, OpenClaw was hit with nine CVEs in four days.
This wasn't a coordinated audit by a single security team — it was multiple independent security researchers finding bugs in the same period. The CVEs spanned the full range: path traversal, server-side request forgery (SSRF), authentication bypass, cross-site scripting (XSS), information disclosure, unauthorized configuration modification, WebSocket hijacking, log injection, insecure default permissions.
Each CVE alone is a serious security issue. Put nine together and the picture gets clearer — this isn't random bad luck in code quality. It's systemic security debt at the architectural level.
The Common Root
On the surface, these nine bugs are all different. Path traversal exploits a flaw in file handling logic. SSRF exploits incomplete URL validation. Auth bypass exploits session management. But step back and they have a shared root: OpenClaw exposes too large an attack surface.
OpenClaw has a web server, so it has attack surfaces for XSS and auth bypass. It has a file management API, so it has attack surface for path traversal. It has a feature that initiates external requests, so it has attack surface for SSRF. It has WebSocket connections, so it has attack surface for WebSocket hijacking. It has a logging system, so it has attack surface for log injection. It has a configuration API, so it has attack surface for unauthorized config modification.
Every feature introduces a corresponding attack surface. More features, more attack surface. It's simple math: attack surface grows linearly with code and feature count, while the engineering effort required to guarantee security grows exponentially with attack surface.
OpenClaw's code is in the tens of thousands of lines, its features span a web UI, REST API, WebSocket, file management, config management, skill system, and plugin marketplace — each an attack surface that needs independent protection. Keeping all of those simultaneously bug-free takes far more security engineering than an open-source project typically has resources for.
NanoClaw Doesn't Have These Attack Surfaces
Go through the nine CVEs one by one:
Path traversal — NanoClaw has no file management API. File access is controlled via container mounts, and the agent can only see directories explicitly mounted into the container.
SSRF — NanoClaw provides no interface that lets external users trigger internal requests. The agent's network access inside the container is bounded by container network policy.
Auth bypass — NanoClaw has no web authentication system. No login page, no session cookies, no JWT tokens.
XSS — NanoClaw has no web interface. No HTML rendering, no possibility of user input being reflected into a page.
Information disclosure — NanoClaw exposes no HTTP endpoints. No error pages to leak stack traces, no APIs to return internal state.
Unauthorized config modification — NanoClaw has no config API. Configuration is managed through a local .env file, and only someone with physical access to the server can modify it.
WebSocket hijacking — NanoClaw doesn't serve WebSocket connections. It's a WebSocket client connecting to WhatsApp, but it doesn't accept inbound WebSocket connections.
Log injection — NanoClaw's logs are produced by the orchestration layer outside the container, and the agent can't write directly to the host's log system.
Insecure default permissions — NanoClaw's containers run with minimum privileges by default, and users don't have to configure permission boundaries manually.
Nine CVEs, none of them apply to NanoClaw. Not because NanoClaw's code is better — because NanoClaw doesn't have these attack surfaces. You can't attack a web server that doesn't exist, can't bypass an authentication system that doesn't exist, can't traverse a file management API that doesn't exist.
Attack Surface Minimization
Security engineering has two basic strategies.
The first is hardening: accept the attack surface and try to protect every part of it. That means every API endpoint needs authentication and authorization checks, every user input needs validation and escaping, every file operation needs path normalization, every network request needs URL allowlisting. This is what OpenClaw does — it has lots of security code protecting lots of features.
The second is elimination: don't create attack surface you don't need. If you don't need a web interface, don't have a web server. If you don't need a file management API, don't implement one. If you don't need a config API, use a local file for configuration.
NanoClaw uses the second strategy. Its attack surface isn't small because it has lots of security code — it's small because its feature surface is small. Fewer features, less attack surface. Less attack surface, fewer places to protect. Fewer places to protect, lower probability of error.
Nine CVEs in four days isn't a failure of the OpenClaw team — given their resources, their security work is actually decent. It's the inevitable result of an architectural choice. When you choose to build a feature-rich platform, you simultaneously sign up to carry a huge attack surface. And protecting that attack surface requires sustained, high-quality security engineering — which most open-source projects can't maintain long term.
NanoClaw's choice is different: do fewer features, have less attack surface, need less security engineering. This isn't laziness. It's an honest assessment of your own resource constraints.