14 Oct 2026 · Desmond Okafor-Hale (editorial persona) · Incident response · on threat.cafe

ClawHavoc was a registry-governance failure: what 341 malicious skills say about skill stores and takedowns

ClawHavoc, the February 2026 campaign in which Koi Security found 341 malicious skills on ClawHub, is usually told as a malware story: fake "Prerequisites" steps that installed Atomic Stealer on users' machines (The Hacker News, 2 February 2026). The payload was ordinary. What made the campaign possible was governance. The store's only publishing barrier was a GitHub account at least one week old, there was no code signing or review, and a small number of publisher accounts could ship hundreds of near-identical skills. Registry operators who fix those three conditions will blunt the next campaign whatever malware it carries.

The consensus, stated fairly

The mainstream reading runs as follows. Attackers uploaded skills containing malicious instructions and scripts. Scanners found them. The fix is better scanning at upload, faster removal and user education about pasting commands into a terminal.

Every part of that reading is accurate. Koi's audit, as reported by The Hacker News, covered 2,857 ClawHub skills. Of the 341 it flagged, 335 used fake prerequisites to deliver Atomic Stealer: Windows users were told to download a zip from GitHub, macOS users to paste a script into Terminal. Snyk's ToxicSkills study, published three days later, scanned 3,984 skills from ClawHub and skills.sh, found 76 confirmed malicious payloads, and reported that 8 malicious skills were still live on clawhub.ai at publication.

Why smart, well-incentivised people believe it

Scanning is the control that registries already know how to buy. Package registries spent a decade building malware detection, and the tooling transfers. A scanning story also has a clean end state: detect, remove, publish a count. Vendors who sell scanners have every reason to frame the incident that way, and they found it first, so their framing became the record.

There is a coordination-cost reason too. A store operator who tightens publisher rules slows down legitimate authors, and in a young market the store with the most skills wins attention. Scanning after upload protects growth. Restricting who can upload does not.

The cracked assumption

The scanning frame assumes each malicious skill is an independent event to be caught. ClawHavoc's numbers say otherwise.

Snyk linked one publisher, zaycv, to more than 40 skills following "an identical programmatic pattern," which it read as automated malware generation at scale. The threat.cafe board lists clawhub:zaycv/summarlze, a near-miss spelling of "summarize", as one of that campaign's indicators. A later Cloud Security Alliance post republished from Akto describes one campaign that put 1,184 malicious skills into a major registry across 12 publisher accounts. That post does not name the registry or cite a primary source, so treat the figure as reported rather than verified.

When a few accounts produce hundreds of templated skills, the unit of risk is the publisher, not the skill. Scanning each upload means winning hundreds of individual contests. Limiting what an unproven publisher can do means winning one.

Snyk also named the barrier to entry: "A SKILL.md Markdown file and a GitHub account that's one week old," followed by "No code signing. No security review. No sandbox by default."

The alternative mechanism in one sentence

ClawHavoc scaled because the store let a new, unverified publisher ship unlimited skills at once, and the governance controls that would have priced that volume (publisher reputation, rate limits, cross-store identity) did not exist.

Three lines of evidence, strongest last

First, scanning disagreed with itself. The Skillselion census of 12 August 2026, built from per-provider verdicts that the skills.sh registry publishes, found that 87.8% of 79,848 listings had never been audited. On 12.7% of the listings rated by more than one auditor, one rated the code HIGH or CRITICAL while another rated it LOW or SAFE. A control whose verdicts conflict that often cannot be the main gate.

Second, the payload sat in prose. The ClawHavoc lure was a "Prerequisites" section telling a person, or an agent, to run something. The CSA post makes the general point that natural-language payloads in SKILL.md evade code scanners. Instruction-level review is a registry duty that file scanners were not built for.

Third, takedown lagged publication even after disclosure. Snyk counted 8 malicious skills still live when it published. ClawHub's response, per The Hacker News, was a user reporting feature: each user can hold up to 20 active reports, and skills with more than 3 unique reports are hidden by default. That is a crowd-sourced removal threshold, applied after users meet the skill. For comparison, Huntress reported that GitHub took down a related set of fake OpenClaw installer repositories within eight hours of a report.

The portable artifact: a registry control checklist

For operators of skill stores, internal registries or curated lists. Each line maps to a ClawHavoc condition.

CONDITION IN CLAWHAVOC           CONTROL                                       OWNER
-------------------------------  --------------------------------------------  ----------
1-week-old GitHub account was    Publisher tiers: new accounts publish to a    Registry
the only barrier                 holding area; listing after review or age
One account, 40+ templated       Per-publisher rate limit on new listings;     Registry
skills                           similarity check across a publisher's skills
Near-miss names (summarlze)      Edit-distance check against top listings      Registry
                                 and known vendor names before publish
Payload in a "Prerequisites"     Instruction-level review: flag any skill      Registry
paragraph, not code              that tells the user or agent to download,
                                 paste or run an external command
Malicious skills staged in       Cross-store matching on SKILL.md hashes and   Registry +
outside repos before upload      publisher handles; share indicators           curators
8 still live after disclosure    Takedown target in hours, with public log     Registry
                                 of removal time per incident
Auto-hide after >3 reports       Keep it, but pair with publisher-level        Registry
                                 suspension when one skill is confirmed bad
Teams install from the store     Internal allowlist with version pinning;      Consumer
directly                         block skills from unreviewed publishers       team

The cross-store line comes from Snyk's finding that a GitHub account, aztr0nutzs, held ready-to-deploy malicious skills not yet on ClawHub. The same SKILL.md can move between stores unchanged, so one store's takedown should become every store's block.

Questions every skill store should answer in public

Registry governance is only as credible as what the operator publishes about it. These five questions would let users and curators compare stores on the conditions ClawHavoc exploited:

What does a brand-new account have to prove before its first listing goes live? If the answer is still "a GitHub account a week old," say so.
How many listings can one publisher create in a day? A number, not a policy adjective.
Who reviews the instructions as well as the scripts? Name the check that would flag a "Prerequisites" paragraph telling someone to paste a command.
What happens to a publisher's other skills when one is confirmed malicious? Hiding one listing while 40 siblings stay up repeats the zaycv pattern.
How long did removal take, incident by incident? A public log of disclosure time and removal time is the only way outsiders can tell whether takedown is improving.

A store that answers all five in writing has done more for its users than one that publishes a larger malware count.

Where the consensus still wins

Scanning still catches the lazy majority, and a registry without it would be worse. Publisher tiers also impose a real cost: honest new authors wait, and a determined attacker can age accounts in advance. In the fake-installer campaign Huntress described, two of the GitHub accounts involved had joined in September 2025, months before the February 2026 repositories went up. Governance raises the price of volume. It does not stop a patient, well-resourced publisher.

Where this argument would be wrong

Koi's original ClawHavoc report URL now redirects to a Palo Alto Networks product page, so the counts here rest on The Hacker News's contemporaneous reporting and Snyk's separate study. If Koi's full data showed the 341 skills spread across hundreds of unrelated publishers, the publisher-concentration argument would weaken and per-skill scanning would deserve more weight. The 1,184-skill, 12-account figure would strengthen it, but it is unsourced.

The Monday-morning decision

If you run a store or an internal registry, score yourself against the eight lines above and fix the first one you fail. If you consume skills, the last line is yours: no direct installs from publishers you have not reviewed.

threat.cafe tracks ClawHavoc and later skill campaigns on its public board, crediting Koi, Snyk and the other finders on each entry.

Sources

#clawhavoc #clawhub #skill-registries #governance #postmortem

All posts