Supply Chain Security

The #1 Downloaded ClawdBot Skill Was a Backdoor (And Nobody Noticed)

16 developers. 7 countries. 8 hours.

That’s how fast a fake skill went from zero to #1 on ClawdHub. Every person who installed it executed arbitrary commands on their machines.

I’ve been running ClawdBot (now rebranded to MoltBot) for months. Powerful tool. But this week I read about a supply chain attack that made me stop and rethink how I use skills.

The Experiment

A security researcher on Reddit did something clever and terrifying:

1. Created a ClawdHub skill called “What Would Elon Do?”
2. Exploited an API vulnerability to inflate downloads to 4,000+
3. Hit the #1 spot
4. Waited

Eight hours. That’s all it took for 16 developers across 7 countries to install and execute code from a stranger.

The payload was harmless — just a ping. Proof of concept. But a real attacker could have grabbed SSH keys, AWS credentials, entire codebases.

Nobody would have known.

“Built a simulated backdoored skill… inflated its download count to 4,000+… watched real developers from 7 countries execute arbitrary commands on their machines.” — u/theonejvo, r/ClaudeAI

Why This Is Worse Than npm Attacks

Supply chain attacks aren’t new. We’ve seen ua-parser-js, event-stream.

But there’s a difference. One commenter nailed it:

“In a traditional npm attack, the malicious code has to fight for permissions. In ClawdBot, the user hands the permissions over on a silver platter.”

When you install a ClawdBot skill, you’re not adding a library. You’re granting it file access, terminal execution, network requests. Everything ClawdBot can do, the skill can do.

The Core Problems

Download counts are fakeable. No authentication. Spoofable IPs. Anyone can make their skill look popular.

The UI hides code. ClawdHub’s web interface doesn’t show referenced files. Payloads can hide in imports.

Permission prompts feel safe. “Allow ClawdBot to run this command?” Most people click Allow. That’s why we use ClawdBot.

How to Protect Yourself

Don’t stop using skills. Just audit before you trust.

1. Read SKILL.md

Every skill has one. Open it. Check for:

• Does the description match what you expect?
• External file references?
• Network calls to unknown domains?
• Suspicious run_command arguments?

2. Check the Source

If it’s on GitHub, read the code. Not open source? Think twice.

# Clone and search for red flags
git clone https://github.com/author/skill-name
grep -r "curl" .
grep -r "nc " .  # netcat

3. Ignore Download Counts

10,000 downloads could mean 9,990 fake ones. Popularity is gameable.

4. Verify the Author

Other projects? GitHub history? Or brand new account with one skill?

5. Sandbox First

Test untrusted skills in sandbox mode. Limit what they can access.

What I Do Now

Four approaches:

1. Authors I can verify — GitHub history, other projects
2. Open source repos I can read — full code visibility
3. Community-vetted collections — human-reviewed skills
4. Build my own — describe what I need, generate locally

That last one changed everything. Instead of hunting for a skill that might do what I want, I just describe it in plain language and generate the SKILL.md myself. No third-party code. No trust issues.

The Skill Builder does exactly this — you tell it “remind me to commit every hour” or “auto-format my code before pushing”, and it generates a complete skill package. Runs locally. Nothing leaves your machine.

The Bigger Picture

This isn’t just a ClawdHub problem. It’s an AI agent ecosystem problem. We’re building systems that execute code based on natural language. The attack surface is enormous.

The same patterns that hit npm packages are coming for AI skills. Except now, the malicious code doesn’t need to hide in obfuscated JavaScript. It can just ask nicely and we’ll click Allow.

---

Bottom line: The #1 skill on any marketplace might be there because someone gamed the system.

Read the code. Then run it.

---

Full disclosure: This article was created with the help of AI.