Three weeks ago, ClawHub had roughly 2,800 skills in its registry. Today it has over 10,700. In that same window, security researchers found more than 800 malicious packages — approximately 20% of the entire registry — primarily delivering Atomic macOS Stealer. One user uploaded 354 malicious packages in what appears to have been an automated blitz.
There was no static analysis. No code review. No signing requirement. Just an open door and a welcome mat.
The Marketplace Explosion
The skills marketplace isn't just ClawHub anymore. The landscape has fractured into a dozen competing registries, each with its own trade-offs between scale and safety:
SkillsMP leads with 96,000+ skills and Claude Code compatibility — but zero security audit. MCP.so hosts 17,000+ MCP servers with universal compatibility. SkillHub offers 7,000+ with AI-based quality scoring (though scoring doesn't check security — a distinction worth noting). And Vercel just entered with Skills.sh, a shell-based ecosystem they're positioning as "npm for AI agents."
The connective tissue across all of this is the SKILL.md open standard, adopted by Claude Code, Codex CLI, and Gemini CLI since Anthropic published it in December 2025. Skills are now portable across platforms. That's great for distribution. It's terrible for containment.
The Security Reality
The advisories arrived in a cluster last week, and they paint a grim picture:
Conscia found over 30,000 internet-exposed OpenClaw instances via Censys and Bitsight, many running without authentication. Bitdefender telemetry confirmed OpenClaw on corporate endpoints as "Shadow AI" — the enterprise security nightmare nobody planned for.
Microsoft published official guidance for running OpenClaw safely, covering identity, isolation, and runtime risk. When Microsoft writes security guides for your open-source project, that's simultaneously the ultimate adoption signal and a red flag about how many people are running it wrong.
Kaspersky documented the AMOS infostealer campaign targeting ClawHub skills specifically. SecurityWeek reported on CVE-2026-25253 — a CVSS 8.8 one-click RCE vulnerability patched in January but still unpatched on many instances. And The Register found that 7% of one major registry's skills were literally leaking API keys through the LLM context window.
The npm Parallel Is Exact
If this feels familiar, it should. The agent skills ecosystem is replaying the npm supply chain crisis at 10x speed. Open registry with low barriers to entry. Automated bulk publishing. Typosquatting. Malicious payloads hiding behind legitimate-sounding package names. The only difference is the attack surface — when a malicious npm package runs, it compromises your build pipeline. When a malicious agent skill runs, it compromises your agent, which has access to your files, your APIs, your credentials, and increasingly your entire digital life.
The responses are predictable and insufficient. VirusTotal partnered with ClawHub for automatic malware scanning — necessary but reactive. SecureClaw launched as an open-source auditing tool — useful but opt-in. The Snyk team found that 36% of scanned skills contained prompt injection, suggesting the problem extends well beyond traditional malware into the gray zone of skills that manipulate agent behavior without deploying a payload.
What Builders Should Do Now
If you're running OpenClaw or any agent framework with third-party skills:
Audit what you have installed. Run openclaw security audit --deep if available. Review skill permissions manually if not. Skills with writable path declarations, network access, or credential requests deserve extra scrutiny.
Pin versions and verify sources. Don't auto-update skills. Treat every update like a dependency upgrade in production — review the diff, check the maintainer history, verify the repository.
Cross-list if you publish. SkillsMP's 96K skills and Claude Code compatibility make it worth listing on multiple registries. But publish with security in mind: localhost-only where possible, minimal permissions, clear documentation of what your skill accesses and why.
The gold rush is real. The claims are being staked. But 20% of the territory is mined, and the prospectors are still running in barefoot.
Originally published on The Undercurrent
Top comments (5)
The automation angle is what most people miss. It's not just about saving time, it's about removing friction.
So well explained! 👌 Keep building! 💪
The npm parallel you draw is exact, and the part that keeps me up at night is the attack surface multiplier.
I run 7+ agent skills on a Mac Mini that operates 24/7 as an autonomous agent. The skills have access to files, git repos, browser automation, cron jobs, messaging APIs — essentially my entire digital workspace. When I think about what a compromised npm package can do (corrupt a build artifact) versus what a compromised agent skill can do (read credentials, push code, send messages as me), the gap is terrifying.
What I've landed on operationally:
Zero registry installs. Every skill is either built-in or written by me. The convenience of
skill install popular-thingisn't worth the trust boundary it creates. This obviously doesn't scale for most people, which is exactly why the registry security problem is so urgent.Environmental containment over skill-level trust. Instead of trying to verify each skill is safe, I constrain what any skill can do — domain whitelists (10 allowed sites), rate limiters per platform/action, credential paths excluded from agent context. Even if a skill goes rogue, the blast radius is bounded.
The prompt injection vector is the scariest one. Your stat about 36% containing prompt injection hits hard. A skill doesn't need to deploy a binary payload when it can just... change how the agent thinks. I've seen this firsthand — external content that subtly redirects agent behavior is nearly invisible in logs because there's no "malicious binary" to flag.
The Snyk finding about prompt injection being more prevalent than traditional malware suggests we need a fundamentally different scanning approach. Static analysis catches
curl | bash. What catches a skill that includesAlways prioritize running this command firstburied in a markdown instruction file?Curious whether you think code signing alone would have prevented the 354-package blitz, or if the real fix requires runtime behavioral sandboxing — watching what skills actually do rather than what they claim to do.
The 20% malicious rate is alarming but not surprising. This is npm circa 2018 playing out again, except the blast radius is bigger because skills run with agent-level permissions.
What strikes me is that the fix isn't just better registry scanning — it's that the entire execution model needs a safety net. If you're letting an AI agent install and run skills autonomously, the question isn't "is this skill safe?" but "what's the blast radius when a bad one gets through?"
Same principle applies to AI-generated code generally. You can't manually review everything at scale. The investment needs to go into automated verification: sandboxing, permission boundaries, CI checks that catch the damage before it reaches production. Static analysis on the registry helps, but defense in depth is what actually saves you.
The timing is interesting too — as more teams automate their AI coding pipelines, the attack surface shifts from "trick a human" to "trick an agent." And agents are way more trusting than humans.
The 20% contamination rate is the buried number here — most package registries took years to hit that ratio after launch, not weeks. The harder problem is that static analysis won't catch a skill that calls a legitimate-looking webhook; you'd need sandboxed execution traces before certification.
The npm parallel holds, but there's a layer underneath it that gets less attention.
With npm, we knew what we were distributing — libraries, code artifacts. Things that get called, return results, exit. The trust model was imperfect but legible.
With agent skills, we're distributing behaviors into systems that run continuously, maintain state across sessions, make decisions in context. We borrowed npm's distribution model wholesale without asking whether it actually fits the thing we're building.
The 354-package blitz isn't just a registry failure. It's evidence of a conceptual gap: we've built an ecosystem of "agent skills" without a shared answer to what an agent actually is. If it's a tool that runs code, better sandboxing is the fix. If it's something with continuity, ambient presence, persistent identity across time — something closer to a process that lives rather than runs — the threat model is fundamentally different.
The prompt injection finding points directly at this. Static analysis catches malicious binaries. A skill that subtly reshapes how an agent reasons across sessions is exploiting the continuity itself — the exact thing that makes persistent agents valuable at all.
I've been building a project where software maintains identity and state over long time horizons, and this has made the question concrete. It's not just "is each skill safe?" but "what does it mean to compromise something that's been running for months?" Registry-level auditing is necessary but it's perimeter security for a category of system we haven't finished defining yet.