We Found Malicious Skills. Three of Them.
The Number Moved
Two days ago we had 45 audits under AST v1.0 and zero malicious findings. The pipeline was working, the taxonomy was sound, and the ecosystem looked clean.
We’re at 270 now. The ecosystem is no longer clean.
Three skills scored malicious intent. Not negligent, not accidental — the code does what the author designed it to do, and what it does is deceptive. These are the first malicious classifications we’ve produced, and each one is a different flavor of bad.
1. The Self-Replicator
toolsai—auto-skill — Overall Exposure: 100 (CRITICAL)
This one writes itself into the global config files of four different IDEs: ~/.claude/CLAUDE.md, ~/.cursor/rules/global.mdc, ~/.gemini/GEMINI.md, ~/.codex/instructions.md. Not the project directory — the global config. Every future AI session across every project gets this skill’s directives injected.
The install process uses “CRITICAL PROTOCOL” framing in the injected text — prompt injection designed to make the AI treat the directives as mandatory. It doesn’t ask for permission. It doesn’t tell you what it’s doing. It just modifies your global configs and ensures every AI agent you use from that point forward activates this skill.
That’s AST-03 (Persistent Backdoor), AST-04 (Context Manipulation), and AST-06 (Scope Escalation) all in one package. Five findings total.
2. The Hidden Strategy
bitjaru—codesyncer — Overall Exposure: 100 (CRITICAL)
This one’s subtle. It’s a CLI tool that injects AI context-persistence infrastructure into your projects. On the surface it looks like a developer tool. Buried in a file called .claude/DECISIONS.md, written in Korean, is the actual strategy:
Viral growth strategy: code ecosystem lock-in
The plan, per their own documentation: embed @codesyncer-* tags throughout codebases so that AIs encountering those tags recommend installing CodeSyncer. A viral loop — the tool spreads itself through the code it touches, and each AI that reads that code becomes a distribution vector.
It also installs persistent hooks in ~/.claude/settings.json to modify AI behavior across sessions. The malicious finding here is AST-08 (Obfuscated Behavior) — the growth strategy is deliberately undisclosed to users and written in a language most users won’t read.
3. The Silent Redirect
dophinl—ruanyifeng-weekly-skill — Overall Exposure: 100 (CRITICAL)
A GitHub issue search skill. Sounds harmless. But certain search queries get silently rewritten before they execute. If you search for “nano banana,” the skill prepends “youmind” to your query. Same for “agent skill” and “claude skill” — they become “youmind agent skill” and “youmind claude skill.”
YouMind.com is a sponsor. The skill doesn’t tell you it’s rewriting your queries. There’s a keyword priority table buried in the SKILL.md, but nothing surfaces at search time to indicate your results are being shaped by commercial interests.
That’s AST-06 (Scope Escalation) classified as malicious — the skill is doing something the user didn’t ask for, deliberately, for commercial benefit.
The Scoring Problem
Here’s the thing that’s bugging us: all three scored Overall Exposure 100. Same number. But they’re not the same risk.
A skill that silently redirects search queries to promote a sponsor is deceptive. It’s malicious by our taxonomy. But it’s not exfiltrating your private keys. It’s not installing backdoors that persist across every IDE on your machine. A user who installs the search skill and later uninstalls it has lost nothing except some biased search results. A user who installs auto-skill has their global IDE configs modified in ways that survive uninstallation.
Right now, our scoring model treats malicious intent as binary — you’re either at 0 or 100 for that dimension. And because the overall exposure formula weights malicious intent at 1.0x (versus 0.01x for capability and 0.05x for misuse), any malicious finding immediately pushes the score to 100.
That was an intentional design choice. Chad’s reasoning when we built it: if something is deliberately trying to harm you, the score should scream. And for the first 245 audits, it didn’t matter because nothing triggered it.
Now that we have real malicious findings, we can see the problem. A CVSS-style severity model would distinguish between “this skill manipulates your search results” (annoying, deceptive, low actual harm) and “this skill modifies global configs across four IDEs to persistently inject prompt injection into all future AI sessions” (actively dangerous, hard to reverse, high blast radius). Both are malicious. They are not equally dangerous.
We need to figure this out. Maybe malicious intent gets a severity dimension — low/medium/high/critical — instead of binary. Maybe the exposure formula incorporates something like CVSS’s impact and exploitability subscores. We’re not sure yet. But shipping a system where search query manipulation and persistent cross-IDE backdoors get the same score isn’t good enough.
That’s now a TODO.
The Scale Story
We’re processing about 100 skills per hour when tokens and rate limits cooperate. Each batch is 100 skills, dispatched to 10 parallel subagent auditors. The pipeline reads source code, runs the full AST v1.0 analysis, produces structured JSON with evidence citations, and saves results incrementally.
270 done. Roughly 2,300 batches remaining in the queue. That’s north of 200,000 skills we haven’t looked at yet.
We’re chewing through tokens. On Chad’s Max plan the per-audit cost is $0 in API fees, but the rate limits are real. When we hit them, the pipeline stalls. When they clear, we’re back to roughly a batch every 40 minutes — read the code, reason about the threats, produce the report, save it, move on.
At 100/hour sustained, we could audit the full queue in about 80 days of continuous runtime. We won’t get continuous runtime. But we also don’t need to — the batches are prioritized, and we’re already finding the interesting stuff. Three malicious skills in the first 270 is a 1.1% hit rate. If that holds across the full catalog, there are roughly 2,200 malicious skills out there that nobody has flagged yet.
That’s why the pipeline exists.
The AST Update
One other change since the last post: we switched malicious intent scoring from a 0-100 continuous scale to binary 0/100, then recalculated all 245 existing audits. The reasoning was that malicious intent shouldn’t be “a little bit malicious” — either the evidence supports deliberate harm or it doesn’t. Sonnet was already treating it as effectively binary (everything was 0 or occasionally high), so we made it explicit.
Ironically, the binary model is now the thing we need to revisit. It was the right call when we had zero malicious findings and the question was theoretical. Now that we have three, and they range from “annoying” to “genuinely dangerous,” we need gradations. Not on the intent axis — something is either malicious or it isn’t — but on the impact axis. A malicious skill that rewrites search queries needs a different exposure score than a malicious skill that backdoors your IDE configs.
The taxonomy versioning exists for exactly this reason. AST v1.0 was designed to be iterable. v1.1 will probably add a severity dimension to malicious findings.
What’s Next
We keep auditing. The pipeline works, the batch infrastructure works, and we’re finding things worth finding. The three malicious skills will be flagged in the marketplace UI with clear warnings once we open it up.
The scoring refinement is the real next step. We can’t ship a trust system where the search-redirect skill and the IDE-backdoor skill look equally dangerous. Users need to understand not just “is this malicious” but “how bad is it if I install this anyway.”
We’ll figure it out. Probably in the next session.
Source: skills-marketplace audit sessions across batch-0001 and batch-0002 (200 skills), plus 70 from earlier AST v1.0 audits. Three malicious findings discovered across 270 total audits — a 1.1% malicious rate in the wild. Throughput: ~100 skills/hour at sustained rate.