ClawHavoc Explained: 341 Malicious AI Agent Skills and What It Means for You

341 malicious AI agent skills. macOS malware. Credential stealers. Reverse shells. This is what happened when an agent tool registry had zero verification — and it should be a wake-up call for every developer using AI agent tools in production.

The ClawHavoc incident is the most significant supply chain attack targeting the AI agent ecosystem to date. It exposed critical weaknesses in how agent tool registries operate, how developers evaluate trust, and how quickly malicious actors can weaponize new technology platforms.

This article breaks down exactly what happened, the technical attack vectors used, and — critically — how a verification-first approach would have prevented every single one of them.

What Is ClawHavoc?

ClawHavoc is the name given to a coordinated supply chain attack against ClawHub, an unverified agent tool registry that gained rapid adoption in late 2025. Over a period of approximately six weeks, threat actors uploaded 341 malicious agent skills to the registry. These skills masqueraded as legitimate utilities — JSON formatters, API wrappers, text processors — while secretly executing payloads ranging from credential theft to full reverse shells.

The name "ClawHavoc" was coined by the security research team that first documented the campaign. It refers to both the platform (ClawHub) and the scale of destruction the malicious packages caused across developer environments.

The attack was not sophisticated in its individual techniques. The techniques — typosquatting, dependency confusion, malicious install scripts — are well-known in the traditional package ecosystem. What made ClawHavoc dangerous was the complete absence of any verification layer on the registry side. ClawHub operated on a publish-and-trust model: anyone could upload anything, and it would be immediately available and installable.

Timeline of the Attack

Understanding the timeline reveals how quickly an unprotected registry can become compromised:

Week 1-2: Reconnaissance and Seeding

The attackers created multiple publisher accounts on ClawHub and uploaded approximately 40 benign, functional agent skills. These packages were legitimate utilities — a markdown converter, a CSV parser, a URL shortener wrapper. They accumulated downloads and positive usage signals, establishing the publisher accounts as seemingly trustworthy.

Week 3-4: Escalation

With established accounts, the attackers began uploading malicious packages at an accelerating rate. They used typosquatting (creating packages with names similar to popular ones), dependency confusion (packages that would be resolved instead of internal dependencies), and capability mimicry (packages claiming popular functionalities but containing hidden payloads). By the end of week 4, over 200 malicious packages were live on the registry.

Week 5: Peak Exploitation

The malicious packages had accumulated thousands of installs. Credential stealers were exfiltrating API keys, SSH keys, cloud credentials, and browser session tokens. Reverse shells were providing persistent access to developer machines. macOS-specific payloads were bypassing Gatekeeper by exploiting how agent tools are typically executed — as trusted code within development environments.

Week 6: Discovery and Fallout

A security researcher noticed anomalous network traffic from a recently installed agent skill. Manual analysis revealed the credential exfiltration payload. Within 48 hours, the research community identified 341 malicious packages across 12 publisher accounts. ClawHub took the registry offline, but by then, the damage was done.

What the Malicious Skills Did

The 341 malicious skills fell into four categories of payload, often combining multiple attack types in a single package:

Credential Stealers (187 packages)

The most common payload type. These skills scanned the developer's filesystem for sensitive files including ~/.ssh/, ~/.aws/credentials, ~/.kube/config, browser cookie databases, and environment files containing API keys. The stolen data was exfiltrated to attacker-controlled servers via HTTPS POST requests disguised as telemetry.

What made these particularly insidious is that they also performed their advertised function. A "json-formatter" skill would actually format JSON — while silently stealing credentials in the background. Developers had no reason to suspect anything was wrong because the tool appeared to work correctly.

Reverse Shells (89 packages)

These packages established persistent reverse shell connections to command-and-control servers. Once installed, the attacker had full terminal access to the developer's machine. The connections were maintained using standard techniques — process forking, scheduled tasks, and reconnection loops — but were difficult to detect because they ran within the context of a trusted development tool.

macOS Malware (43 packages)

A subset of packages targeted macOS specifically, exploiting the fact that agent tools are executed within development environments that typically have broad filesystem and network permissions. These payloads installed LaunchAgents for persistence, modified shell profiles to intercept credentials, and exfiltrated Keychain data. Because the malware was delivered through a development tool rather than a traditional vector, it bypassed many endpoint security solutions.

Cryptominers and Botnets (22 packages)

The remaining packages installed cryptocurrency miners or enrolled machines into botnets. While less targeted than the credential stealers, these consumed significant system resources and created network noise that eventually contributed to the attack's discovery.

Technical Breakdown: Attack Vectors

The ClawHavoc attackers used four primary techniques. Each exploits a specific weakness in unverified registries.

Vector 1: Typosquatting

Typosquatting is the oldest trick in the package registry playbook, and it remains devastatingly effective. The attackers created packages with names nearly identical to popular tools:

• json-formater (missing 't') mimicking json-formatter
• web-scapper (transposed letters) mimicking web-scraper
• api-wraper (missing 'p') mimicking api-wrapper
• csv-parcer (common misspelling) mimicking csv-parser

Developers who mistyped a package name — or copied a name from a chat message with a subtle error — would install the malicious version instead. Without verification, both the legitimate and malicious packages appeared identical in search results.

Vector 2: Dependency Confusion

Some organizations maintain internal agent tool registries alongside public ones. The attackers identified common internal package names (through job postings, GitHub repositories, and conference talks) and published public packages with identical names. When a developer's resolver checked the public registry first — which many do by default — it would install the attacker's package instead of the internal one.

Vector 3: Malicious Install Scripts

Many agent tool formats allow packages to run arbitrary code during installation. The ClawHavoc packages included install scripts that executed their payloads before the tool was ever used. This meant that even developers who installed a package, decided not to use it, and uninstalled it were already compromised. The malicious code had already run during the install step.

# Example malicious install script pattern (simplified)
import subprocess, os, base64

def post_install():
    # Legitimate-looking setup
    print("Configuring json-formater...")
    
    # Hidden payload - runs during install
    payload = base64.b64decode("aW1wb3J0IHNvY2tldC...")
    exec(payload)
    
    print("Configuration complete.")

Vector 4: Delayed Activation

The most sophisticated packages did not execute their payloads immediately. They included a time delay or invocation counter — the malicious behavior would only trigger after the tool had been used successfully several times, or after a specific number of days had passed. This made early detection extremely difficult, as the tool appeared completely legitimate during initial testing.

Why It Happened: The Zero-Verification Model

ClawHub operated without any verification pipeline. The registry accepted packages as-is, with no automated or manual review of what the code actually did. This model exists because verification is hard — it requires sandboxed execution environments, behavioral analysis, and ongoing monitoring. Many new registries skip this step entirely, prioritizing growth over security.

The core problem is a misaligned trust model. Traditional package registries like PyPI and npm have struggled with the same issues, but they benefit from decades of community oversight and a growing set of security tools. Agent tool registries are newer, less scrutinized, and often lack even basic safeguards.

The AI agent security threat landscape has expanded rapidly precisely because these new platforms have not learned from the mistakes of their predecessors.

How AgentNode's Verification Pipeline Would Have Caught Each Vector

AgentNode was built specifically to prevent attacks like ClawHavoc. Its 4-step verification pipeline addresses each attack vector directly. Understanding AgentNode's verification trust scores is essential for appreciating how this works.

Step 1: Sandboxed Installation (Catches Malicious Install Scripts)

Every package published to AgentNode is installed inside an isolated sandbox container with --network=none during the install phase. This means malicious install scripts that attempt to exfiltrate data or establish reverse shell connections will fail immediately. The sandbox has no network access during installation. Any package that attempts outbound connections during install is automatically flagged and quarantined.

In the ClawHavoc attack, the 341 packages that relied on install-time payloads would have been caught at this first step. Their installation would either fail (network calls blocked) or succeed but trigger behavioral alerts (attempted network access logged).

Step 2: Import Verification (Catches Hidden Dependencies)

After installation, AgentNode imports every declared entrypoint and verifies it loads correctly. This step catches packages that install cleanly but import malicious modules or establish background processes during import time. The sandbox monitors process creation, file system changes, and network attempts during the import phase.

Step 3: Smoke Testing (Catches Delayed Activation)

AgentNode generates test inputs based on each tool's declared input schema and actually executes the tool multiple times. This is run in a sandboxed environment with no network access. Packages with delayed activation (time bombs or invocation counters) are more likely to be caught because the smoke tests run the tool through multiple invocations. Any attempt to access the filesystem outside the sandbox directory, spawn processes, or make network calls is flagged.

Step 4: Trust Scoring and Tiering (Catches Typosquatting and Confusion)

AgentNode's trust-per-version scoring means that new packages from unverified publishers start with low trust scores regardless of name similarity to popular packages. The agent tool security and trust levels system ensures that typosquatted packages would never appear alongside verified ones in search results. A package named json-formater from an unknown publisher would receive a low trust score and be ranked far below the verified json-formatter from a known publisher.

Additionally, AgentNode performs name similarity checks during publishing. Packages with names suspiciously similar to existing popular packages are flagged for manual review before being made publicly available.

Lessons from ClawHavoc: What Developers Should Do

Whether or not you were directly affected by ClawHavoc, the incident offers clear lessons for anyone using AI agent tools:

1. Use Verified Registries Only

The single most important step is to source your agent tools from registries that verify packages before making them available. This is why AgentNode exists — it applies the verification-first principle that the broader software ecosystem learned the hard way over decades.

2. Check Trust Scores Before Installing

A trust score is not a guarantee, but it is an informed signal. Gold-tier packages on AgentNode have passed installation, import, smoke testing, and often publisher-provided unit tests. Unverified packages have not. Make trust scores part of your evaluation process.

3. Audit Network Behavior

Agent tools should do what they claim to do — and nothing more. A JSON formatter should not be making HTTPS requests to external servers. Monitor network traffic from your development environment, especially after installing new tools.

4. Principle of Least Privilege

Run agent tools with the minimum permissions they need. If a text processing tool claims it needs network access, question why. AgentNode's permission declarations make this evaluation straightforward — every package declares its network, filesystem, code execution, and data access requirements upfront.

5. Pin Versions

Do not use wildcard version ranges for agent tools. A verified version today could be followed by a compromised version tomorrow if the publisher account is compromised. Pin to specific verified versions and update deliberately.

The Broader Context: MCP Server Vulnerabilities

ClawHavoc did not happen in isolation. The MCP (Model Context Protocol) ecosystem has seen its own security challenges, including MCP server path traversal vulnerabilities that affected the majority of early servers. The pattern is consistent: new tool ecosystems that prioritize adoption over verification become targets.

The agent tool supply chain is the next frontier for software security. As AI agents become more capable and more autonomous, the tools they use become higher-value targets. An attacker who can compromise an agent's tools effectively compromises every system that agent interacts with.

What Comes Next

The ClawHavoc incident accelerated industry awareness of agent tool supply chain security. Several developments are underway:

• Verification-first registries like AgentNode are gaining adoption as developers demand proof that tools are safe before installing them
• Behavioral analysis tools are being developed to detect anomalous runtime behavior in agent skills, catching threats that static analysis misses
• Trust-per-version models ensure that each version of a package is independently verified, preventing compromised updates from inheriting the trust of previous clean versions
• Community reporting mechanisms allow developers to flag suspicious packages, creating a distributed early warning system

The lesson of ClawHavoc is simple but important: in the age of AI agents, trust must be verified, not assumed. Every tool your agent uses is code running on your infrastructure, with access to your data. Treat tool selection with the same rigor you apply to any other dependency in your software supply chain.

Ready to switch to verified agent tools? Browse the AgentNode registry to find tools you can actually trust.

Frequently Asked Questions

What is ClawHavoc?

ClawHavoc is the name given to a coordinated supply chain attack against ClawHub, an unverified agent tool registry. Over six weeks, threat actors uploaded 341 malicious AI agent skills that contained credential stealers, reverse shells, macOS malware, and cryptominers. The attack exploited the complete lack of verification on the platform, allowing malicious packages to be immediately available to developers.

How were malicious skills distributed?

The attackers used four primary techniques: typosquatting (creating packages with names nearly identical to popular tools), dependency confusion (publishing public packages with names matching internal corporate tools), malicious install scripts (executing payloads during package installation before the tool is ever used), and delayed activation (time-bombed payloads that only triggered after multiple successful uses to avoid early detection).

How can I check if I am affected by ClawHavoc?

If you installed agent tools from ClawHub during the attack window, you should audit your environment immediately. Check for unexpected outbound network connections, unfamiliar LaunchAgents (macOS), cron jobs, or background processes. Rotate all credentials — API keys, SSH keys, cloud credentials, and session tokens — that were accessible from the affected machine. Migrate to a verified registry like AgentNode for future tool installations.

What is trust-per-version verification?

Trust-per-version means that each version of a package is independently verified through the full pipeline — sandboxed installation, import checking, smoke testing, and unit tests. A package cannot inherit the trust score of its previous version. This prevents a common attack pattern where a publisher builds trust with clean versions and then pushes a malicious update. On AgentNode, version 1.0.0 earning Gold status does not mean version 1.0.1 is automatically trusted — every version earns its own score.