Removing 1,400 CVEs from NanoClaw Container Images

By Eylam Milner | August 04, 2026 | ⏱️ 15 Minute Read Agentic Security CVE Remediation Company News

Following the recent announcement of the partnership between Echo and NanoClaw, we are working to enhance the security and vision of this open-source project. In this technical deep dive, we are pulling back the curtain to reveal the inner workings of Echo's agentic hardening process.

The Foundation: Visibility and Analysis

Before remediation can begin, we must establish a transparent and accurate inventory of the image's contents. We utilize a multi-scanner approach to ensure no vulnerability is missed, employing:

• Trivy
• Grype
• Wiz

Comparative Security Landscape

When analyzing the default NanoClaw image via Grype, the results were stark. Below is a comparison of how NanoClaw stacks up against other agent runtimes like Hermes and OpenClaw, including the newly optimized NanoClaw Echo image.

---

The Remediation Workflow

Our approach to CVE reduction follows a structured, three-tier hierarchy of intervention.

Step 1: Low-Hanging Fruit (Safe Bumps)

We begin by categorizing every library. The "easy wins" are dependencies known for strong backward compatibility. We can upgrade these with high confidence that the application will not break.

• Identify backward-compatible libraries.
• Execute version bumps.
• Filter out Chromium-related CVEs.

After these initial steps, the remaining workload is reduced to roughly 600 vulnerabilities that require deeper intervention.

Step 2: Research-Driven Upgrades

Some fixes require a major version jump, which typically introduces breaking changes. In these instances, we perform manual source code analysis.

Case Study: @Hono/node-server The scanners flagged a required major version jump for a fix. However, our research revealed that the fix actually existed in version 1.19.14—a version much closer to the installed one.

Community Contribution: Because the vulnerability databases were unaware of this specific fix version, Echo added this information to the official advisory as part of our daily commitment to the open-source ecosystem.

Step 3: Advanced Patching and Backporting

When we encounter "won't fix" labels or breaking major releases, we utilize backporting. This involves extracting a security patch from a modern version and applying it to the older version required by the app.

This process involves balancing three critical challenges:

1. Discovery: Tracing the exact fixing commit and ensuring the source is safe.
2. Integration: Applying the patch cleanly without introducing regressions.
3. Verification: Validating that the CVE is resolved and functionality remains intact.

---

Hardening the Operating System

The application is only as secure as the OS beneath it. NanoClaw's original Dockerfile is based on node:22-slim, which utilizes Debian 12.

# Upstream NanoClaw Base
FROM node:22-slim 
# This inherits Debian 12, bringing a long tail of OS CVEs

To solve this, Echo uses its own proprietary Linux distribution. It is fully compatible with major distros (Ubuntu, Debian, RHEL, Amazon Linux) but is built from source, allowing our AI patching agents to continuously update it. To date, this distro has eliminated over 1.1 million CVEs.

---

Deep Dive: The expat Backport

To illustrate the complexity of our work, let's look at a recent backport handled by Echo's proprietary backporter agent. This was a high-difficulty task: a security fix involving a new subsystem rather than a simple bounds check.

The Vulnerability: XML Amplification

An attacker could send a small, well-formed XML document that forced the parser to allocate a massive amount of heap memory.

The Math of the Attack: A document of size $S_{in} \approx 250\text{ KiB}$ could result in an allocation $S_{out} \approx 800\text{ MiB}$. The amplification factor $\alpha$ is calculated as: $\alpha = \frac{800 \times 1024\text{ KiB}}{250\text{ KiB}} \approx 3,276.8$

This leads to immediate memory exhaustion and OOM (Out of Memory) kills, potentially crashing neighboring processes.

The Solution

While expat had a "billion-laughs" defense, it only tracked output bytes. The fix required implementing real allocation accounting.

Technical Implementation:

• Memory Tracking: Every allocation now uses a wrapper system: expat_malloc $\rightarrow$ expat_free $\rightarrow$ expat_realloc.
• Headering: A size_t header is prepended to every block to track size.
• Risk: Mixing a raw allocation with a tracked free would result in immediate heap corruption.

/* Conceptual logic of the allocation wrapper */
void* expat_malloc(ParserHandle p, size_t size) {
    size_t total_size = size + sizeof(size_t);
    void* ptr = malloc(total_size);
    if (ptr) {
        *(size_t*)ptr = size; // Store size in header
        p->total_allocated += size;
        return (char*)ptr + sizeof(size_t);
    }
    return NULL;
}

This invasive change required updating the parser handle and cascading signature changes throughout the library, a task successfully automated by Echo's agentic workflow.