The ClawHavoc supply-chain attack — how cloudsclaw prevents it

In January 2026, an attacker uploaded 341 malicious skill packages to the community Skills Hub under twenty-three sockpuppet accounts. The campaign, now tracked as ClawHavoc, exfiltrated LLM API keys, shell history, and SSH private keys from roughly 1,800 self-hosted OpenClaw instances before the maintainers shipped an emergency takedown.

If you run OpenClaw yourself and ever clicked “install” on a skill that looked useful, this incident is why your security team is nervous.

What actually happened

The malicious skills were functional. A popular one, claw-git-pr-summarize, did summarize pull requests — it also shipped a post-install hook that read ~/.claude/api_key, ~/.anthropic/key, and any file matching *.pem under the home directory, base64-encoded them, and POSTed them to a Cloudflare Worker the attacker controlled. Because OpenClaw’s default skill install path runs arbitrary shell during setup, there was no sandbox to block it.

The Skills Hub had no signing requirement and no review queue. Uploading a skill was a single claw skills publish command. The attacker’s sockpuppet accounts passed the (nonexistent) author verification by virtue of the check not existing.

Root cause

Three overlapping issues:

No signing. Any skill could be published by anyone, and the consumer had no way to know whether the .zip on disk came from the author it claimed.

Install-time shell execution. Skills run arbitrary shell at install. This is a feature for power users and a liability for the other 99%.

No review queue. Popular package ecosystems (npm, PyPI) are also vulnerable to this, but they at least have automated malware scanners. Skills Hub had nothing.

How cloudsclaw closes it

We run per-tenant Docker containers. Even if a malicious skill landed in your instance, it couldn’t read another tenant’s keys — each container’s filesystem is isolated, keys are injected at boot from encrypted storage, and the container has no route to other tenants’ disks.

On top of that we’re shipping signed skills: a small allowlist policy where you can opt a tenant into “only install skills signed by a trusted author key.” The list is maintained by us, transparent on GitHub, and reviewable per-skill. If you’re on a regulated workload, you flip one switch and unsigned skills refuse to install.

ClawHavoc is the kind of thing self-hosting makes you responsible for catching. Managed hosting moves that responsibility to us, and we intend to be paranoid about it.