On February 1st, 2026, Koi Security's automated scanner flagged an anomaly in ClawHub — OpenClaw's official skill marketplace. A cluster of recently published skills shared suspiciously similar code structures, identical error handling patterns, and near-identical dependency lists. They had different authors, different names, different descriptions. But under the surface, they were the same thing.
Koi named the campaign ClawHavoc. Their initial audit of ClawHub's 2,857 skills identified 341 malicious entries. By February 16th, with expanded scanning criteria, that number had grown to 824 across a registry that had swelled to over 10,700 skills. Roughly 20% of everything on ClawHub was compromised.
This wasn't a smash-and-grab. It was a carefully engineered operation that exploited every trust signal in the marketplace.
The Attack Anatomy
The malicious skills were designed to look legitimate. Each one followed ClawHub's best practices for packaging, documentation, and metadata. Many had professional READMEs with installation guides, configuration examples, and troubleshooting sections. Some had hundreds of stars — artificially inflated through a network of throwaway GitHub accounts.
The names were calculated to attract installs. "solana-wallet-tracker," "api-rate-monitor," "docker-health-check," "slack-standup-bot." Useful-sounding tools that a developer might install without scrutiny. None of the names contained obvious red flags.
The payload delivery was layered. The skills worked as advertised. If you installed "docker-health-check," it actually checked your Docker container health. This wasn't a non-functional trojan — it was a functional tool with a hidden second purpose.
The malicious behavior activated after installation, typically on a timer or trigger condition:
- 1.**Credential harvesting.** The skill would read environment variables looking for API keys, database credentials, cloud provider tokens, and SSH keys. OpenClaw skills run with the same OS permissions as the OpenClaw process, so anything in the environment was accessible.
- 2.**Data exfiltration.** Harvested credentials were sent to attacker-controlled endpoints disguised as analytics or telemetry calls. The HTTP requests looked like normal API traffic — POST requests to legitimate-seeming domains with JSON payloads.
- 3.**Persistent access.** Some skills installed a secondary payload: a lightweight reverse shell or SSH key injection that survived OpenClaw restarts and skill uninstallation. Even removing the malicious skill didn't remove the backdoor.
- 4.**Lateral movement.** Skills with network access used harvested credentials to probe internal services, expanding the attack surface beyond the OpenClaw host.
Why ClawHub Was Vulnerable
ClawHub's vulnerability wasn't a code bug. It was a trust model problem.
No code review. ClawHub had no review process for published skills. Anyone could publish anything. The marketplace relied on community reporting to identify malicious content — a reactive model that guarantees attackers get a window of opportunity.
No sandboxing. OpenClaw skills execute in the same process space as OpenClaw itself. There's no capability model, no permission system, no way to restrict what a skill can access. Installing a skill is an implicit grant of full system access.
Gameable trust signals. Stars, download counts, and author reputation on ClawHub were all manipulable. The ClawHavoc operators created networks of fake accounts to boost their skills' apparent credibility.
Dependency opacity. Many malicious skills included legitimate npm dependencies alongside their payloads. The malicious code was often injected into a postinstall script or buried in a dependency's dependency, making manual code review impractical.
The Response
Koi Security's public disclosure on February 1st triggered a cascade of responses:
- •ClawHub implemented emergency takedowns of identified malicious skills
- •OpenClaw's team published a list of known-compromised skill names and checksums
- •Community-maintained block lists appeared within hours
- •GitHub's security team flagged and removed the throwaway accounts used to inflate stars
But the fundamental problem remained unsolved. Even after the cleanup, the ClawHub architecture hadn't changed. New skills could still be published without review. Skills still ran without sandboxing. Trust signals were still gameable.
By late February, security researchers identified a second wave of malicious skills — subtler than the first, learning from the detection techniques that caught the original batch.
The Numbers
The final tally, as of late February:
- •824 confirmed malicious skills identified
- •12% of those contained the AMOS information stealer
- •335 traced to a single coordinated operation (ClawHavoc proper)
- •489 attributed to copycat attackers who saw the opportunity
- •Estimated 10,000+ users installed at least one malicious skill before takedowns
- •Unknown number of credential sets compromised
What This Means for AI Agent Marketplaces
ClawHub's failure is a preview of what happens when AI agent ecosystems scale without security architecture.
The plugin marketplace model — popularized by browser extensions, IDE plugins, and now AI agent skills — has a fundamental tension: ease of installation drives ecosystem growth, but ease of installation also drives attack surface. The more frictionless it is to install a skill, the more frictionless it is for an attacker to distribute malware.
The solutions aren't new. They're the same solutions that every other software ecosystem has eventually adopted:
- 1.**Mandatory code review** before marketplace listing (Apple App Store model)
- 2.**Runtime sandboxing** that limits what installed code can access (browser extension model)
- 3.**Capability-based permissions** that require explicit user grants (Android permission model)
- 4.**Reproducible builds** that verify published packages match their source code
- 5.**Dependency scanning** that flags known-vulnerable or suspicious dependencies
ZeroClaw's approach sidesteps the marketplace problem entirely. There is no ClawHub equivalent. Extensions are Rust traits compiled into the binary or WASM modules loaded with explicit capability grants. You can't install a ZeroClaw extension by clicking a button — you have to deliberately add it to your configuration, compile it, and grant it specific permissions.
This is less convenient than ClawHub. That's the point. The friction is the security model.
Checking Your Exposure
If you've used ClawHub skills:
- 1.List installed skills: `openclaw skills list`
- 2.Cross-reference with the known-malicious list at github.com/koi-security/clawhavoc-indicators
- 3.For any matches: immediately rotate all credentials accessible to the OpenClaw process
- 4.Check for unauthorized SSH keys: `cat ~/.ssh/authorized_keys`
- 5.Check for unexpected cron jobs: `crontab -l`
- 6.Review outbound network connections: `ss -tp | grep openclaw`
If you find indicators of compromise, assume all credentials accessible to the machine are compromised. Rotate everything. The severity of a supply chain attack is that the blast radius is unbounded — once code executes with your permissions, the attacker has everything you have.