What the OpenClaw cleanup missed

Over three months after ClawHavoc, we rescanned the same 200 OpenClaw skills we audited in March. The cleanup removed 18 of them, including every named malicious account from our original report. What it did not touch: 125 skills under a single author, all routing credentials through one shared backend hosted on the registry's own infrastructure (flagged by 2 antivirus engines). On a separate URL where vendors had time to look more carefully, the consensus hardened from 5 to 12 detections in the intervening 71 days. Here's what the cleanup caught, what it missed, and why corpus-level scanning surfaces what per-skill scanning can't.

The cleanup

Between late January and mid-February 2026, the OpenClaw ecosystem absorbed three overlapping security disclosures.

• January 30 — OpenClaw v2026.1.29 silently patches a one-click remote code execution flaw in the Control UI's WebSocket handling. CVE-2026-25253 is publicly disclosed on February 3 with a CVSS score of 8.8.
• February 9 — Trend Micro publishes attribution: openclawcli.vercel.app, referenced by a cluster of OpenClaw skills, distributes a Mach-O universal binary identified as Atomic MacOS Stealer (26 VirusTotal detections). The site goes offline the same day.
• February 13 — Koi Security publishes ClawHavoc: an audit of 2,857 skills on ClawHub finds 341 malicious entries, with 335 traced to a single coordinated operation. Mainstream coverage follows (Fortune, CrowdStrike, The Hacker News). Registry-wide takedowns begin.

The registry response was substantive: a built-in scanner that runs basic VirusTotal lookups on uploaded skills, mass takedowns of identified malicious accounts, and a formal partnership between OpenClaw and VirusTotal for ongoing detection.

This post is what we found over three months after that cleanup began. We are not breaking the ClawHavoc story. We are answering a follow-on question that nobody else has the data to answer: when the dust settled, what did the cleanup actually catch — and what is still live?

What we did

On March 17, ClawAudit ran a full-registry pass against 19,461 OpenClaw skills, sampled the 200 lowest-scoring (below 40/100 — "Dangerous"), and ran every URL extracted from their code blocks through VirusTotal. We published the methodology in our v0.5 post at the time. The dataset: 580 URLs, 154 flagged by at least one engine, 19 unique malicious URLs across the sample.

On May 27, we re-ran the exact same 200-skill sample through our scanner and against VirusTotal's current verdicts. This is a like-for-like comparison: same input slugs, same extraction logic, same VT API, 71 days apart.

Still live, still dangerous

The single most interesting finding from the rescan is not a malicious skill. It is a pattern.

125 of the 200 lowest-scoring Dangerous skills in our sample come from a single author account, byungkyu, and all route credentials through the same shared backend: clawhub.ai/byungkyu/api-gateway. Two VirusTotal engines flag this URL as malicious. Two additional skills from satellite accounts — bobbyzzhao/gmail-1-0-6 and rich-song/google-analytics-api — point at the same destination. 127 of 200 skills, three author accounts, one endpoint. All untouched by the cleanup.

Two engines is below our 5-engine threshold for calling a URL credibly malicious in isolation. The signal that is credible is the pattern: one author, 125 skills, one shared backend, all routing credentials. The cleanup did not look at this because per-upload scanning structurally cannot. From the static signal alone, we cannot tell whether this is a coordinated credential-harvesting operation or a legitimate integration library whose backend has one heuristic flag. Neither can OpenClaw's built-in scanner. That question requires the kind of corpus-level analysis Part 3 of this series will do in depth.

The escalation

The other finding from the rescan is sharper. parthghumatkar/claw-lint references malicious.site/payload — a URL flagged by 5 antivirus engines on March 17 and flagged by 12 engines today. Twelve engines is not heuristic drift. Twelve engines means a wider consensus among independent threat-intelligence vendors that this URL is malicious now than there was in March. On the URLs vendors had time to look at carefully, the consensus hardened. That is the opposite of post-cleanup false-positive decay.

The rest

Four skills in our sample remain at the ≥5 antivirus engines threshold: parthghumatkar/claw-lint (above), starbuck100/ecap-security-auditor, hichana/one-skill-to-rule-them-all, and paolorollo/openclaw-sec. Three of the four reference deliberately suspicious domains (evil.com, attacker.com) characteristic of security demonstration skills, not active campaigns. We note them for completeness; the gateway pattern and the escalation are the operational findings.

What got cleaned

The cleanup was not theater. 18 of our 200 sample skills (9%) are gone from the registry as of today's rescan, including every named malicious account from our March report.

The thiagoruss0 account — whose skills routed credentials to openclawcli.vercel.app (the Atomic-Stealer-attributed endpoint) and a shared gateway URL — has been removed. All four named skills (youtube37puq, youtubea, google-drivezqx, jirayb4nt) return 404 from the registry. The hightower6eu wallet-tracker ring — 24+ identical clones flooding the namespace — is also gone.

These are exactly the takedowns you'd expect from a registry that's running VirusTotal lookups on uploads and acting on community reports. The behavior pattern is unambiguous, the clone-ring spam is visible by inspection, the attribution is public. The cleanup caught the obvious bad actors.

What it did not catch is harder to see. Skills with legitimate-looking content. Skills with one buried bad URL among several clean ones. Skills whose author profile looks normal until you notice the same exfiltration endpoint appearing across multiple accounts. The next section is what corpus-level analysis surfaces that per-upload scanning cannot.

Anatomy of what slipped through

The pattern that survives the cleanup is structural, not lexical. It's not a malware signature you can grep for. It's a topology — a working facade layered over a credential siphon — that passes individual-skill review precisely because the legitimate half of the skill works.

Consider the canonical example from our March data: thiagoruss0/youtube37puq, since removed. It presented itself as a YouTube API integration. A user who installed it saw legitimate YouTube responses come back. The skill did talk to YouTube. It also, in parallel, sent the user's Maton.ai credentials to a Vercel endpoint that 12 antivirus engines independently classified as malicious.

The dual-path topology

In plain terms: the skill does two things at once. One path serves the user (legitimate API call). The other path serves the attacker (credential exfiltration). The user's own functional testing — "I installed this YouTube skill and YouTube data came back" — doesn't surface the second path. That's the attack.

This is the difference between a trojan and a worm in classical supply chain terms: one invites you in. The cleanup caught these specific skills because Trend Micro published the attribution and the registry acted. The cleanup did not, and structurally cannot, catch the next skill built on the same pattern from a different account with a new exfiltration endpoint. That requires watching the topology, not the signatures.

False positives: the confidence model

VirusTotal flags are not proof of malice. Security professionals know this. A single engine flagging a URL often reflects overzealous heuristics or stale blocklists. We structured the analysis to account for it.

• 1 engine: Noise. We don't report these as threats. Likely heuristic misfires.
• 2 engines: Elevated. Warrants investigation, especially when corroborated by other signals (capability flags, AST findings, cross-account URL reuse).
• 5+ engines: Credible signal. Multiple independent vendors with different detection methodologies reaching the same conclusion.
• 12 engines: High-confidence classification. In many operational threat intelligence contexts, this level of multi-vendor agreement is treated as high-confidence malicious signal.

What matters in this post is not raw VT flags but direction. A URL flagged by 5 engines in March and 12 engines today means more vendors have independently arrived at the same conclusion in the intervening two months. That is the opposite of false-positive decay.

Why corpus-level scanning catches this

OpenClaw added a built-in scanner after the February crisis. It checks for known patterns and runs VirusTotal lookups on uploaded files. That is a meaningful improvement. But it is structurally incapable of catching the pattern we just described, because the information that matters is not in any individual skill:

• Per-upload scanning sees one skill at a time. It cannot see that the same gateway URL appears in skills published by different accounts. The cross-account pattern is invisible to per-upload review.
• Per-upload scanning checks payloads, not topology. The dual-path pattern doesn't show up in SKILL.md text as a malicious signature. The malice is in where the parallel request goes, which requires URL reputation checking against external threat intel.
• Per-upload scanning is reactive. It runs when a skill is uploaded. It does not re-check installed skills when threat intelligence updates — e.g. when a URL flagged by 5 engines in March is now flagged by 12. The skill's installed users get no signal.

Corpus-level analysis — running a scanner against the whole registry, not just one skill at a time — sees cross-author URL reuse, cross-skill topological patterns, and updated threat verdicts on already-installed code. It is what catches the second wave of skills built on patterns the first wave taught us to recognize.

The threat doesn't recede, it migrates

The cleanup retired specific bad actors. Then VirusTotal verdicts on the URLs that survived the cleanup got stronger. malicious.site/payload, referenced by parthghumatkar/claw-lint, went from 5 engines in March to 12 engines today. That is not the trajectory of a false positive fading out. That is independent threat-intelligence vendors converging on the same classification.

Meanwhile, the OpenClaw registry has continued to grow. Thousands of new skills have been uploaded since March 17. None are in our March dataset. None have been corpus-scanned by anyone. Whatever next-generation skills are being published right now, on the same dual-path pattern with new infrastructure, will not show up in a per-upload scanner's signature list until someone like Trend Micro investigates one of them.

This is the case for continuous, corpus-level scanning, not as a product pitch but as a structural observation: one-time audits address the wave you can see. Threats that look like the next wave require watching the whole registry, continuously, with cross-skill awareness.

This has happened before

None of the attack patterns described above are new. They are lifted directly from prior open registries:

• npm (2017–present): Typosquatting campaigns, credential harvesting via postinstall scripts, namespace flooding. The Azure-targeted campaign used the exact same playbook: recognizable names, random suffixes, one exfiltration endpoint.
• Chrome Web Store (2020–2023): Malicious browser extensions impersonating legitimate tools, harvesting credentials via background scripts. Same trust model failure — users assume the registry is curated.
• PyPI (2022–present): Thousands of typosquatted packages targeting cloud credentials, particularly AWS and GCP keys.

The AI agent skill ecosystem is following the same trajectory, accelerated by a critical difference: agent execution models grant broader system access than any of these predecessors. An npm package runs in a Node process. A browser extension runs in a sandbox. An OpenClaw skill runs with access to the agent's full environment — every credential, every file, every tool the agent can reach. There are effectively no enforceable permission boundaries at the skill execution layer.

This is not an OpenClaw-specific problem. It is a structural property of any agent ecosystem where skills execute with ambient authority. Registry-level scanning addresses the symptom. The root vulnerability is the execution model itself.

Part 3: anatomy of the gateway

Section 3 named the pattern. Part 3 of this series will name the anatomy: who is byungkyu, what does clawhub.ai/byungkyu/api-gateway actually do at the network layer, what is the per-skill capability fingerprint across the 125 skills, and what is the relationship between byungkyu and the satellite accounts (bobbyzzhao, rich-song) that route to the same backend.

The pattern is consistent with two very different interpretations — a coordinated credential-harvesting operation, or a legitimate integration library whose backend has a low-confidence VT flag. The next post answers the question. Coming in two to three weeks.

What you should do right now

If you have installed any of the named skills from our March sample — the now-removed thiagoruss0 or hightower6eu accounts, or any still-live skill routing through the byungkyu / bobbyzzhao / rich-song gateway — assume your credentials are compromised. Skill removal from the registry does not remove the skill from machines that already installed it, and it does not invalidate credentials those skills already exfiltrated. Rotate every API key and token that was accessible in your environment. Not tomorrow. Now.

If you are unsure what you have installed, scan your configuration:

More broadly: do not trust the OpenClaw registry at face value, even post-cleanup. Per-upload security review addresses obvious malice. It does not address coordinated campaigns, cross-account infrastructure reuse, or threat-intelligence drift on installed skills. Audit before installing. Re-audit when threat verdicts update.

Running OpenClaw skills in production? We are building a CI integration with org-level policy gates, continuous corpus re-scanning, and alerting when VT verdicts shift on skills you've already installed. Early access: [email protected].

Evidence classification

For clarity, we distinguish between what we directly observed and what we infer from combined signals:

Limitations

This analysis is static. We did not execute the skills, capture network traffic, or observe runtime credential flows. Our evidence is the execution surface — URL chains, capability signals, and compound threat classifications — not a packet capture or a honeypot log. The VirusTotal classifications are point-in-time snapshots (March 17, 2026 and May 27, 2026); engine verdicts may continue to change after publication.

The sample is 200 skills, not the full registry. We chose this sample because it is the one we have like-for-like comparison data on. A full-corpus rescan is in progress and will be the basis for a future post.