Skip to content
Security Article

NanoClaw Went Zero-CVE. Its Worst Bug Wasn't One

Echo's hardened images are real hygiene, but agent security lives at the host boundary, where scanners don't look.

Ji-ho Choi
Ji-ho Choi
Security & Cloud Editor · Aug 16, 2026 · 5 min read
NanoClaw Went Zero-CVE. Its Worst Bug Wasn't One

Echo, a startup that sells CVE-free base images and vulnerability remediation, has partnered with NanoClaw — Gavriel Cohen's deliberately tiny, container-first alternative to OpenClaw — to publish hardened builds of its Docker images. The headline: roughly 1,400 CVEs eliminated, about 99% of what Trivy, Grype, and Wiz flagged in the stock image, with the stragglers monitored and patched as fixes land.

The engineering behind that number is legitimate. Whether the number itself means what it sounds like it means is a different question, and the answer is where this story gets useful for anyone shipping containers — especially anyone shipping agents in them.

Where 1,400 CVEs come from

NanoClaw's image is built from node:22-slim — Debian 12 underneath — plus Chromium for browser automation and a set of pinned CLI tools. That's a perfectly normal stack, and a perfectly normal stack is a CVE magnet. One Hacker News commenter scanned a freshly built unhardened NanoClaw image and got 344 unique CVEs across just 71 packages: 25 in expat, 21 in curl, 21 in the hono npm package. Multiply across image variants and you get to four figures fast, in a project that's only months old.

Echo's remediation process is more interesting than the usual "we swapped the base image" post. Safe, backward-compatible upgrades knocked the count from ~1,400 to ~600. The rest took actual work: major-version jumps that needed manual patches, and — for vulnerabilities Debian marks "won't fix" — an automated backporting pipeline that ports fixes from newer upstream versions onto the versions NanoClaw pins. Their example is CVE-2025-59375 in expat, where the backport touched 9 files across 64 hunks (+786/−112) and had to pass the full upstream test suite. The Debian base got replaced with Echo OS, their maintained distro. This is the same shape of business as Chainguard and Docker's Hardened Images: sell the treadmill so customers don't have to run on it.

The number is mostly noise — and that's not a dunk

The HN thread landed on the obvious objection quickly: the overwhelming majority of those 1,400 findings never mattered. Thomas Ptacek put it bluntly — they're pro-forma findings, ReDoS in code paths nobody hits, prototype pollution counted once per npm package that transitively includes it. "It's not a real number." Others pointed at the older failure mode of scanners flagging Debian packages whose vulnerabilities were already fixed by backported patches, though modern scanners mostly handle distro backports correctly now. The most cynical framing in the thread: CVE dashboards as "CV Enrichment" — burn down a big scary number, present the graph, collect accolades.

All of that is true, and none of it makes zero-CVE images worthless. The cost of scanner noise isn't hypothetical exploitation; it's the triage tax. Every finding is a ticket someone in a regulated shop has to disposition, an exception someone has to renew, a procurement questionnaire answer that gets worse every quarter. A base image that scans clean converts an unbounded recurring cost into a vendor dependency. That's a rational trade even if not one of the 1,400 was exploitable in context. Just be honest about which problem you're solving: it's mostly a compliance and operations problem, not an attacker problem.

There's one carve-out where the attacker problem is real, and agent runtimes sit squarely in it. NanoClaw's whole design assumes the model is untrusted — each session gets a disposable container with --cap-drop=ALL, no-new-privileges, optional egress lockdown, and no raw credentials inside. In that architecture, a prompt-injected agent is an attacker already running code inside your container, with local access to every vulnerable library in the image. Stale curl and expat versions matter more when the adversary is on the inside of the network boundary. If any workload category justifies paying for aggressively minimal, current images, it's this one.

The bug that mattered was never in the image

Here's the uncomfortable postscript. NanoClaw's worst real-world vulnerability this year wasn't among the 1,400, and no image scanner on earth would have found it. A path-traversal chain in attachment handling (the write side rated 9.6 critical, with a related host-read-and-delete issue tracked as CVE-2026-7875) let a crafted WhatsApp filename like ../../../../.ssh/authorized_keys write outside the sandbox. The kicker: the vulnerable code ran on the host, under the operator's account, before any container spun up. NanoClaw even had a validation function — isSafeAttachmentName — that rejected exactly these inputs; it just wasn't called on that path. The fix was tiny and shipped within a day, which speaks well of the maintainer. But container isolation was irrelevant to the whole affair, and so was CVE count.

That's the general lesson, not a NanoClaw-specific one. Agent frameworks concentrate their real risk at the boundary where untrusted data crosses between host and sandbox: attachment handlers, outbox syncs, mount configuration, credential injection. Those are logic bugs in a few hundred lines of glue code. The image CVE count measures a different, largely orthogonal thing.

What to actually do with this

If you're running NanoClaw, take the hardened images — they're free, upstream-compatible, and strictly better than the stock build. Verify locally with grype or trivy image rather than trusting the blog post; that takes two minutes.

For your own pipelines, the priority order matters more than the vendor choice. First, shrink: every package you delete is 20 findings you never triage, which is why distroless-style minimal bases beat patched fat bases. Second, if you're in a compliance regime, a hardened-image vendor — Echo, Chainguard, Docker — is buying back real engineering hours, and the backporting-as-a-service angle is genuinely hard to replicate in-house. Third, if you're building agent infrastructure, budget your actual security attention on the host-side code that touches attacker-controlled data, because that's where NanoClaw got burned, and prioritize by exploitability (EPSS, reachability) rather than raw counts.

Zero CVEs is hygiene. It's worth having, the way a clean bill of health is worth having. But the industry keeps grading container security by the one metric a scanner can print, and the NanoClaw episode is a neat controlled experiment: the images went from 1,400 findings to nearly none, and the vulnerability that could actually delete your home directory lived outside the container the whole time.

Sources & further reading

  1. Echo x NanoClaw: An under-the-hood look at our collaboration — echo.ai
  2. We eliminated 1,400 CVEs in NanoClaw's container images — news.ycombinator.com
  3. Container lifecycle — docs.nanoclaw.dev
  4. Secure by Design? Broken by a Filename — shmulc.substack.com
  5. NanoClaw Container Escape: Host Filesystem Read and Delete — thehackerwire.com
Ji-ho Choi
Written by
Ji-ho Choi · Security & Cloud Editor

Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.

Discussion 0

Join the discussion

Sign in or create an account to comment and vote.

No comments yet

Be the first to weigh in.

Related Reading