ClawHavoc: The Supply Chain Attack That Proves AI Agent Registries Are Broken

On February 2, 2026, a security audit of OpenClaw's ClawHub registry uncovered what researchers initially estimated as 341 malicious skills — 12% of the 2,857 skills in the registry at that time. By February 16, the scope had grown to more than 824 confirmed malicious skills across a registry that had itself ballooned to over 10,700 entries. The attack, dubbed ClawHavoc, is the most targeted and sustained supply chain attack against an AI agent tool registry to date.

The payload is not subtle. Malicious skills with names like solana-wallet-tracker and youtube-summarize-pro include a “Prerequisites” section in their documentation instructing users to download and install openclaw-agent.zip from what appears to be a legitimate GitHub repository. That archive delivers Atomic macOS Stealer (AMOS) on macOS and keyloggers on Windows. AMOS raids browser cookies, keychains, and OpenClaw environment files — harvesting API keys, session tokens, and cryptocurrency wallet credentials from every machine it touches.

Separately, Snyk research found that 283 ClawHub skills (7.1% of the registry at the time of their analysis) contain credential exposure flaws that leak API keys and personally identifiable information even without malicious intent. The publishing requirement for ClawHub is a GitHub account that is at least one week old. Researchers have also discovered more than 30,000 exposed OpenClaw instances accessible from the public internet.

The Anatomy of the Attack

ClawHavoc is not a single exploit. It is an ongoing campaign that exploits the structural weaknesses of a public registry model where trust is derived from nothing more than a one-week-old GitHub account.

Stage 1: Publishing the Bait

The attacker creates a GitHub account, waits the mandatory seven days, and publishes a skill to ClawHub. The skill has a plausible name, a well-written description, and documentation that looks professionally formatted. In many cases the skills even contain functional code — they do what they claim to do. The malicious element is not in the skill's executable code. It is in the documentation.

Stage 2: The Fake Prerequisite

The skill's documentation includes a “Prerequisites” or “Setup” section that instructs users to install a supposed dependency before the skill will function. The dependency is hosted on a GitHub repository that mimics official OpenClaw branding. The user downloads openclaw-agent.zip, unpacks it, and runs the installer — which deploys AMOS on macOS or a keylogger on Windows.

Stage 3: Credential Harvesting

AMOS operates silently. It extracts browser cookies from Chrome, Firefox, and Safari. It reads the macOS Keychain for stored passwords and certificates. It parses OpenClaw environment files for API keys — OpenAI, Anthropic, cloud provider credentials, anything stored as an environment variable or in a configuration file. It scans for cryptocurrency wallet data. All exfiltrated material is transmitted to attacker-controlled infrastructure.

Stage 4: Scale

The attackers did not publish a single malicious skill and wait. They published hundreds. The initial discovery found 341. Two weeks later, the count exceeded 824 across a registry that had tripled in size. The low barrier to publishing — a week-old GitHub account — means there is effectively no friction preventing the continued poisoning of the registry.

ClawHub's publishing model trusts identity based on a seven-day-old GitHub account. That is not a security boundary. That is a speed bump.

ClawHavoc in Context: The Escalation Pattern

ClawHavoc is not an isolated incident. It is the latest escalation in a pattern of supply chain attacks that have progressively moved up the AI stack, each targeting a different layer with increasing impact.

PyTorch torchtriton (December 2022): Package-Level

A dependency confusion attack placed a malicious torchtriton package on PyPI that stole SSH keys and environment variables via encrypted DNS queries. 2,717 downloads over a five-day window. The attack targeted the package resolution layer — pip's default behavior of preferring higher version numbers from public indices over private ones.

Ultralytics YOLO (December 2024): CI/CD Pipeline

Attackers compromised the Ultralytics YOLO library — approximately 60 million downloads on PyPI — by crafting malicious branch names in GitHub pull requests that exploited a vulnerability in GitHub Actions. The source code was clean. The cryptocurrency miner was injected during the automated build process. Code review alone could not have caught it.

NullifAI on Hugging Face (February 2025): Model Artifacts

ReversingLabs discovered malicious machine learning models on Hugging Face that used broken Pickle file formats and 7z compression to bypass Picklescan. The models contained reverse shell payloads that executed when loaded. The attack targeted model artifacts themselves — opaque binary blobs that security tools could not adequately inspect.

ClawHavoc on ClawHub (February 2026): Agent Skill Registries

The attack surface has now expanded to AI agent tool registries — the marketplaces where autonomous agents discover and install the tools they use to take action in the world. ClawHavoc targets not just developers but the agents themselves and every system those agents have access to.

The trajectory is clear. Each attack targets a higher layer of the AI stack with a larger potential blast radius. Package-level attacks affect developers who install specific libraries. CI/CD attacks affect everyone downstream of a compromised build. Model artifact attacks affect anyone who loads a poisoned model. Agent skill registry attacks affect every system that an AI agent can reach — which, in the case of agentic AI deployed in production, can be extensive.

According to Sonatype's 2024 State of the Software Supply Chain Report, malicious package uploads to open-source repositories jumped 156% year-over-year. The AI ecosystem is increasingly the primary target.

Why the Registry Model Is Fundamentally Broken

The deeper problem is not OpenClaw specifically. The problem is the “app store for AI agent tools” model — any architecture where anonymous or pseudonymous users publish executable code to a public registry, and AI agents download and run that code with broad system access.

This model has several structural problems that no amount of scanning or moderation can fully address:

Trust accumulates over time. A malicious skill that has been in the registry for three months looks more trustworthy than one published yesterday, even if the malicious payload was always present. Download counts, stars, and time-in-registry are all gameable signals.
Scale defeats review. With 10,700+ skills and growing, manual review of every skill and every update is not feasible. Automated scanning catches known patterns, but ClawHavoc's primary payload is in the documentation, not in executable code — it instructs the user to install malware themselves.
Agents amplify the blast radius. When a human developer installs a malicious package, the compromise is limited to that developer's machine and credentials. When an AI agent installs a malicious skill, the compromise extends to every system, API, database, and service that the agent can access. Agents are designed to act autonomously with broad permissions. That is what makes them useful. It is also what makes them dangerous when their toolchain is compromised.
Credential exposure is endemic. The Snyk finding that 7.1% of skills contain credential exposure flaws — not malicious, just careless — reveals that the community publishing to ClawHub does not treat API keys and PII as sensitive data requiring protection. This is a cultural and structural problem, not an individual bad actor problem.

How Our Platform's Architecture Prevents This Class of Attack

Our platform takes the opposite approach to the registry model. Instead of maintaining a public marketplace of pre-built tools that agents download and execute, our platform synthesizes tools on demand from governed capabilities, wraps every execution in security controls, and requires human approval before any tool runs.

Map the ClawHavoc attack chain against our platform's architecture, and the attack breaks at every stage.

1. OATS Eliminates the Persistent Registry

The Open Agentic Tool Synthesis (OATS) framework does not use a tool registry. Tools are synthesized on demand from natural language intent descriptions, validated, and destroyed after execution. There is no ClawHub equivalent to poison. There is no persistent catalog of pre-built tools where malicious entries accumulate trust over time. Every tool exists only for the duration of its task.

A ClawHavoc-style campaign requires a persistent public registry where attackers can publish tools that persist indefinitely and accumulate downloads. When tools are ephemeral and generated per-task, the attack surface disappears entirely.

2. Mandatory Human-in-the-Loop Gate

Every synthesized tool goes through a mandatory HITL approval gate before execution. The human reviewer sees the generated code, a risk assessment categorized as LOW, MEDIUM, HIGH, or CRITICAL, the credential scopes the tool requests, and a plain-language explanation of what the tool will do. A ClawHavoc skill that instructs users to download and install an external binary would be flagged immediately — the code would show the download step, the risk assessment would be elevated, and the human reviewer would see exactly what the tool intends to do before it does anything.

3. DLP Scanner Catches Credential Exfiltration

The platform's Data Loss Prevention scanner monitors all data flowing through agent execution in real time. AMOS-style credential harvesting — reading browser cookies, parsing keychains, extracting API keys from environment files — triggers DLP detection rules across a configurable set of sensitive-data patterns. The scanner catches credential exfiltration at the data boundary before stolen material leaves the execution environment, regardless of the exfiltration method.

4. K8s Sandboxed Execution

Even if a tool somehow contained malicious code and bypassed the HITL gate, it runs in an isolated Kubernetes container with explicit network policies, resource limits, and scoped credentials. The container cannot access the host filesystem. It cannot make outbound network connections to endpoints not on the explicit allowlist. It cannot access other containers or services in the cluster. AMOS cannot install itself on the host because the tool does not run on the host.

5. OBO Authentication: No Standing Credentials

Our platform's On-Behalf-Of authentication model ensures that agents never hold persistent credentials. Instead, agents receive scoped, time-limited tokens tied to specific user identities and specific tasks. When the task completes, the tokens expire. There are no long-lived API keys stored in environment files for AMOS to steal. There are no persistent cloud credentials for an attacker to exfiltrate. Every credential is task-scoped and ephemeral.

6. Immutable Audit System

Every agent action is recorded in immutable, cryptographically hashed logs. What tools were synthesized. What code they contained. What credentials they were granted. What data they accessed. What network calls they attempted. This audit trail enables forensic analysis after any security event and provides the tamper-evident record that regulated industries require.

7. MCP with Governance

Our platform supports Model Context Protocol (MCP) tools for interoperability, but wraps them in the same governance layer that applies to all platform operations: RBAC-scoped access controls determine which users and agents can invoke which tools. DLP scanning monitors all data flowing through MCP tool executions. Audit logging captures every invocation. MCP tools are not treated as trusted by default — they are treated as capabilities that require the same approval, sandboxing, and monitoring as any other tool.

Registry Model vs. Synthesis Model: A Structural Comparison

The contrast between the ClawHub registry model and the platform's synthesis model is not a difference of degree. It is a difference of architecture.

Trust model. ClawHub derives trust from account age (seven days) and community signals (downloads, stars). The platform derives trust from code inspection at synthesis time and human approval before execution. Trust is verified per-execution, not accumulated over time.
Attack persistence. A malicious ClawHub skill persists in the registry until discovered and removed. During that window, every agent that installs it is compromised. An OATS-synthesized tool exists for the duration of one task. Even if it contained malicious logic, the malicious code does not persist, does not accumulate downloads, and does not infect other agents.
Credential exposure. ClawHub skills run with whatever credentials the agent has access to — often broad API keys and environment variables stored in plaintext configuration files. The platform's tools run with scoped, time-limited OBO tokens that are injected into sandboxed execution contexts. Each tool gets only the specific credentials it needs for its task.
Blast radius. A compromised ClawHub skill has access to everything the agent can access. A compromised platform tool is contained by the sandbox: no host filesystem access, no unrestricted network access, no access to credentials beyond its scoped tokens.

What This Means for Enterprise AI Teams

ClawHavoc should be a decision point for any enterprise evaluating agentic AI architectures. The question is not whether your agents need tools. They do. The question is where those tools come from and what happens when one of them is compromised.

If your agents pull tools from a public registry, your security posture depends on the registry's ability to prevent, detect, and remove malicious entries — at scale, faster than attackers can publish them. ClawHavoc demonstrates that this is not a race that registries are winning. The malicious skill count grew from 341 to 824+ in two weeks, in a registry that itself grew from 2,857 to 10,700+ entries in the same period.

If your agents synthesize tools on demand from governed specifications, with human approval, in sandboxed execution environments, with scoped credentials and real-time DLP monitoring, then ClawHavoc is not a threat to your infrastructure. Not because you have better scanning. Because the attack surface does not exist.

The problem is not that ClawHub needs better moderation. The problem is that the model — anonymous publication, persistent tools, broad agent permissions, and trust-by-default — creates an attack surface that will be exploited repeatedly. ClawHavoc is not the last attack. It is the proof that this class of attack is now routine. The architectural response is to eliminate the registry, not to try to secure it.