Nanoclaw's 9.6-Severity Path Traversal Ran on the Host Before the Container Even Started

Security researcher Shmulik Cohen published an analysis on July 9 detailing two path-traversal vulnerabilities in Nanoclaw, the containerized personal AI agent with over 250,000 downloads and 30,000 GitHub stars. Both vulnerabilities were patched within a day of disclosure; current versions of Nanoclaw are not affected. The critical finding: both bugs operated on the host process, before the container sandbox was ever invoked.

The Inbound Bug: 9.6 Critical

When Nanoclaw receives a chat attachment, it saves the file to disk by joining a session folder path with the attachment’s filename. That filename comes directly from the incoming message with no sanitization. Cohen sent an attachment named ../../../../../../.ssh/authorized_keys. The ../ segments walked the write out of the session directory and into the home directory, achieving arbitrary file write anywhere the operator account could reach.

The severity score: 9.6, Critical. Remote code execution via a single chat message.

The container, the mount allowlist, the “runs in containers for security” pitch: none of it sat on this code path. The vulnerable function ran in the host process, under the operator’s user account, before any container started. As Cohen wrote: “A container cannot protect a path that never enters it.”

The Outbound Bug: 8.0 High

After the inbound fix shipped, Cohen checked the mirror image. Nanoclaw’s outbound file-send function used the same pattern: joining a folder path with a filename the agent supplies. A prompt-injected agent could request to attach ../../../.aws/credentials, causing the host to read cloud keys off disk and post them to the chat. Exfiltration instead of write, 8.0 severity.

The outbound function’s own source code comment described it as “symmetric with” the inbound handler that had just been patched. The symmetry was documented. The guard was not applied to both sides.

The Fix and the Irony

Nanoclaw already had the exact defense function needed. isSafeAttachmentName rejects .., slashes, and empty names. It was unit-tested and used elsewhere in the codebase. It was not called on the chat attachment path. The fix for a 9.6-severity vulnerability was a single line of code.

The Nanoclaw maintainer shipped both patches within a day of disclosure, according to Cohen’s writeup. The maintainer later consolidated the guard into a shared helper to prevent the class from reopening.

WhatsApp Delivered the Payload, Telegram Blocked It

Cohen verified the full attack chain over WhatsApp using the Baileys library. The ../ characters in the filename arrived intact because WhatsApp’s end-to-end encryption prevented the platform from inspecting or sanitizing the payload in transit.

When Cohen ran the same attack over Telegram, it failed. Telegram rewrote .. into underscores before delivery. The difference: Telegram cloud chats are not end-to-end encrypted, so Telegram’s servers can read metadata and scrub it. The platform that sees more of your data protected the user. The one that sees less, by design, could not.

The Category Problem

Nanoclaw is not a weekend project. It is backed by NanoCo, a Tel Aviv startup that raised a $12 million seed round, according to Cohen’s analysis. Its explicit pitch is containerized execution and zero-trust security posture. Cohen notes that OpenClaw itself carries a similar advisory for the same attack vector.

The architectural lesson applies across the personal AI agent category: these tools accept untrusted input (chat messages) and execute with user privileges. Container isolation only protects what runs inside the container. When the dangerous operation sits on a code path that precedes the sandbox, the security boundary is irrelevant.

A control protects nothing until it sits on every path that reaches the dangerous operation.