Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
Installing a ClawHub skill means running third-party code with your agent's permissions. After the ClawHavoc campaign, the safest default is simple: treat every skill as untrusted until it clears a short review. Check who published it, what permissions it requests, whether its source is inspectable, and whether your install policy would block risky behavior before it reaches production.
Public reporting on ClawHavoc describes a supply-chain campaign that seeded ClawHub with malicious skills delivering Atomic macOS Stealer (AMOS), an infostealer associated with credential theft, browser-cookie theft, wallet theft, and keychain access on macOS. Reports also indicate that the number of identified malicious skills changed materially across scans, so exact totals should be treated as scan-dependent rather than definitive. OpenClaw's June 3, 2026 release, v2026.6.1, appears intended to tighten marketplace controls, but platform changes do not remove the need for operator review.
This checklist focuses on what to verify before installation and what to enforce in policy afterward.
TL;DR: The campaign appears to have succeeded because marketplace publishing controls were weak enough that attackers could impersonate legitimate projects and rely on users to install first and inspect later.
ClawHavoc was effective because it exploited trust, not because it required an especially novel delivery mechanism. Public coverage says attackers published skills that resembled legitimate tools closely enough to pass a casual glance, then used those listings to deliver AMOS to macOS users.
The most important lesson is structural. If a marketplace allows low-friction publishing with limited review, attackers can test names, descriptions, and packaging at scale until something gets installed. That pattern is familiar from package registries and extension ecosystems: weak publisher verification plus broad install permissions creates a supply-chain problem.
Some reports characterize ClawHub's historical publisher requirements as minimal, including an account-age threshold tied to GitHub. That claim is plausible, but because the exact policy details are drawn from third-party reporting rather than primary platform documentation in this draft, it is safer to describe the prior controls as limited rather than state a precise rule as settled fact.
TL;DR: OpenClaw v2026.6.1 reportedly adds more review and policy controls, but those controls should be treated as risk reduction, not a guarantee that a skill is safe.
According to the OpenClaw v2026.6.1 release notes, the release introduces a more structured path for skill publication and stronger operator-side installation controls. The practical takeaway is straightforward: the platform is moving from a permissive, publish-first model toward a review-first model.
Two changes matter most:
The release notes describe a proposal-based workflow for new skills. If that workflow is consistently enforced, it should reduce the chance that obviously malicious skills appear in the marketplace without scrutiny.
The release also describes an operator-install-policy that can restrict what gets installed. That matters because prevention at install time is usually more reliable than trying to detect malicious behavior after a package is already available.
The article's original draft also referenced SQLite-backed install ledgers. If present in the release, that is useful for auditability, but the exact implementation detail matters less than the outcome: operators need a durable record of what was installed, when, and by whom.
TL;DR: Before installing any ClawHub skill, verify the publisher, inspect the permissions, prefer readable source, reject oversized access, and review your install history regularly.
Start with the maintainer, not the marketing copy. Look for a credible development history: older accounts, multiple repositories, issue activity, release history, and signs that the publisher existed before the skill appeared.
Red flags include:
A new account is not proof of malice, but it raises the burden of proof.
Permissions are often the clearest signal available before install. Ask whether the requested access matches the job.
Examples:
If the permission scope is broader than the task scope, stop there.
Readable source code is not a guarantee of safety, but it improves your odds. Open repositories with understandable code, dependency manifests, and a visible change history are easier to evaluate than opaque packages or heavily obfuscated bundles.
If a skill is closed-source, minified beyond practical review, or ships binaries without a clear provenance story, treat that as a meaningful risk signal.
Do not stop at the skill itself. Review what it pulls in.
Check for:
Many supply-chain incidents arrive through transitive dependencies rather than the top-level package users think they installed.
A good install ledger turns suspicion into something testable. Review what is installed, when it was installed, who approved it, and whether the current version still matches your expectations.
In team environments, this matters even more. Shared systems make it easy for one risky install to affect multiple operators or workflows.
| Check | What to look for | Red flag |
|---|---|---|
| Publisher history | Account age, repo history, release cadence, issue activity | New or thin account, copycat naming, no maintenance trail |
| Permissions | Match between requested access and stated purpose | Network, filesystem, or sensitive-data access unrelated to the task |
| Inspectability | Readable source, clear provenance, understandable packaging | Obfuscated code, opaque binaries, unclear origin |
| Dependencies | Reasonable dependency tree and install behavior | Excessive dependencies, suspicious hooks, abrupt maintainer changes |
| Install records | Clear history of installs, versions, and approvers | Unexpected entries or installs nobody can explain |
TL;DR: The best use of operator-install-policy is to encode your review standards so risky skills are blocked by default rather than debated after the fact.
A checklist helps individuals make better decisions. Policy helps teams make fewer bad ones.
If OpenClaw's operator-install-policy supports granular controls, prioritize rules like these:
This is the practical shift from reactive scanning to preventive control. Scanners can help, but they are best treated as a backstop. The stronger pattern is to define what acceptable software looks like before installation is allowed.
ClawHavoc is the name used in public reporting for a supply-chain campaign targeting the ClawHub skill ecosystem. Reports say the campaign used malicious marketplace listings to deliver AMOS to macOS users.
Published counts appear to vary by scan date, methodology, and marketplace growth during the reporting window. The safest framing is that the number was large enough to represent a meaningful marketplace compromise, while avoiding overconfidence in any single total unless confirmed by primary-source data.
It likely improves the baseline if the reported review flow and install-policy controls are enforced consistently. But no marketplace control removes the need to review permissions, provenance, and dependencies before installation.
Check four things first: publisher history, requested permissions, source-code inspectability, and dependency behavior. If any of those look wrong for the task, skip the install.
Not necessarily. A better approach is to separate low-risk from high-risk use cases, enforce policy by default, and require deeper review for anything that requests broad access or touches sensitive data.
The main lesson from ClawHavoc is not that marketplaces are unusable. It is that convenience without verification creates an attack surface attackers will keep revisiting. A short pre-install review catches many of the highest-signal problems early: suspicious publishers, oversized permissions, opaque packaging, and dependency sprawl.
If OpenClaw's newer controls are available in your environment, use them to formalize those checks. Review first, install second, and keep a durable record of what changed. That is a more reliable defense than trusting a marketplace badge or assuming a popular listing is safe.
Discover more content:
