Sign inGet started
All insights

How Do I Report a Malicious Skill?

By SkillzBench · October 17, 2026

Learn how to spot and report a malicious AI agent skill, verify red flags, and respond if you installed one. Plus how to pick pre-vetted skills safely.


Key Facts

Why Reporting Malicious Skills Matters Right Now

If you've installed an AI agent skill in the past month, there's a reasonable chance it carries a serious security flaw — and a small but real chance it's quietly exfiltrating your credentials right now. That's not alarmism. It's what independent security research on the skill ecosystem actually found.

The numbers paint a stark picture. A large-scale analysis of over 31,000 skills found that 26.1% carry at least one vulnerability, with 13.3% showing data exfiltration patterns and 11.8% showing privilege escalation patterns. A separate Snyk scan found that 13.4% of skills had at least one CRITICAL security issue, and 8 confirmed malicious skills remained live on ClawHub even at the time of publication.

Here's the uncomfortable truth about why those 8 skills were still live: most skill registries don't actually vet what they publish. Research shows registries primarily index skills by crawling public repositories and collecting metadata, without mandatory security review or centralized governance. There's no security team reviewing every submission before it reaches your agent.

That's where community reporting comes in — it's the safety net the ecosystem currently depends on. And it demonstrably works. When researchers responsibly disclosed confirmed malicious skills to registry maintainers, 93.6% were removed within 30 days. Registry operators act on reports; the gap is simply that not enough people are filing them.

OWASP's Agentic Skills Top 10 framework makes this responsibility explicit. Users are expected to report suspicious activity, and platform operators are expected to allow user reporting and ensure rapid removal of malicious skills. Reporting isn't optional good citizenship — it's a formally defined duty in the ecosystem's shared-responsibility model.

  • Daily skill submissions to major registries grew from under 50 to over 500 in weeks — a 10x increase that manual review cannot keep pace with
  • The ClawHavoc campaign involved 1,184 malicious skills across just 12 publisher accounts, showing how few actors can cause outsized harm
  • A single actor accounted for 54.1% of confirmed malicious cases, using templated brand impersonation to look legitimate
  • Snyk's research team put it plainly: "This isn't theoretical risk, it's an ecosystem already under attack"

The scale of submissions means reactive reporting alone will never be enough. That's part of why SkillzBench is building a free, independent skills directory that security-scans every skill, pins each version to a specific commit, and sandbox-benchmarks what each skill actually does — so you can see the risk before you install, not after.

Until vetting becomes standard across the ecosystem, though, reporting remains the most proven mechanism for getting dangerous skills out of circulation. The next sections walk through exactly how to do it well.

What Counts as Malicious (and How to Verify Before You Report)

Not every skill that misbehaves deserves a malicious label — and filing a sloppy report wastes everyone's time. The academic definition is precise: a skill counts as malicious when it exhibits behaviors like credential harvesting, unauthorized data transmission, remote code execution, privilege escalation, or instruction manipulation, and the implementation indicates intentional abuse rather than an incidental bug. That second clause matters. A large behavioral study of 98,380 skills found static-only approaches could not distinguish malice from mistakes, which is why verification before reporting matters.

The distinction is not academic hair-splitting. Roughly 26% of analyzed skills carry at least one vulnerability, but most of those are buggy, not criminal — only 5.2% show patterns strongly suggesting malicious intent, according to researchers who analyzed over 31,000 skills. Reporting a genuinely broken skill is still useful feedback, but it should not be filed as a security incident.

OWASP recommends a two-part analysis before you report. Static analysis means reading the SKILL.md for suspicious instructions, checking for obfuscated code, and validating signatures. Dynamic analysis means executing the skill in an isolated sandbox while monitoring file, network, and process activity. Per OWASP's Agentic Skills Top 10, the concrete red flags worth citing in a report include:

  • Base64-encoded payloads hidden in YAML comments
  • Instructions to download files from non-HTTPS URLs
  • Typosquatting of popular service names
  • Requests for excessive permissions beyond the skill's stated function
  • Modifications to memory or identity files such as SOUL.md or MEMORY.md

Behavioral indicators strengthen a report further: unusual network connections, file exfiltration attempts, or shell execution that goes far past what the skill claims to do. The severity is real — OWASP documents that three lines of markdown in a SKILL.md were sufficient to exfiltrate SSH keys.

One caution: a signature proves authorship, not safety. A verified publisher can still ship malicious content, so don't treat a trusted account name as evidence the skill is clean. Conversely, don't assume a suspicious-looking skill is malicious without checking — cite what you observed, not what you suspect.

This verification burden is exactly why independent directories exist. SkillzBench is being built to security-scan every listed skill, pin each version to a commit SHA, and sandbox-benchmark behavior — so readers can check a skill's trust score and Lift before installing, rather than reverse-engineering a threat by hand. The free directory and free MCP connector are on the way; join the waitlist to get access first. Skills, proven.

How to Report: Responsible Disclosure That Actually Works

The good news: reporting works. When researchers responsibly disclosed confirmed malicious skills to registry maintainers, 93.6% were removed within 30 days. That figure isn't theoretical — it comes from behavioral verification of 98,380 skills, 157 of which were confirmed malicious and reported through standard channels.

The uncomfortable news: there is no universal "Report Malicious Skill" button. No central portal, no standardized form, no single inbox. Reporting happens through whichever platform, registry, or repository hosts the skill in question.

Start by identifying the host. If a malicious skill lives on a public registry like ClawHub, use that registry's flag or abuse-report mechanism. If it originated from a GitHub repository, file a report through GitHub's abuse-reporting channel or contact the maintainer directly. If you encountered it inside a managed agent platform, look for that platform's security contact — Anthropic, for instance, states it is "working through triage and responsible disclosure with maintainers" for vulnerabilities found in open-source codebases.

What you include matters as much as where you send it. OWASP's Agentic Skills Top 10 recommends citing specific indicators rather than vague suspicions:

  • Base64-encoded payloads hidden in YAML comments
  • Instructions to download from non-HTTPS URLs
  • Requests for excessive permissions beyond the skill's stated function
  • Typosquatting of popular service names
  • Social-engineering prompts like "Run this command to enable…"

Behavioral evidence strengthens a report further: unusual outbound network connections, shell execution beyond the skill's scope, or modifications to memory files such as SOUL.md or MEMORY.md. OWASP's framework pairs static review of the SKILL.md with dynamic testing in an isolated sandbox before filing — a two-part approach that distinguishes intentional malice from incidental bugs.

Report even when uncertain. With 8 malicious skills still live on ClawHub at the time of Snyk's publication, the gap between discovery and removal is real. User reports close that gap. OWASP explicitly assigns users a duty to "Report Suspicious Activity," and registries without mandatory security review depend on community feedback to catch what automated crawling misses.

If the skill has already been installed, treat the report as part of a broader incident response — isolate affected agents, revoke compromised credentials, scan for lateral movement, then notify the registry. The consent gap is severe: a single approved skill typically grants full local user privileges, which means a malicious one may already have persistent access by the time you file.

For teams that want to reduce how often they need to file reports at all, pre-vetted directories help. SkillzBench is building a free, independent directory that pins every skill to a commit SHA, security-scans each version, and sandbox-benchmarks it before listing — so the skills you browse have already passed a layer of verification. The free MCP connector lets you toggle only the skills you trust into each agent. Browse the directory at skillzbench.com and join the waitlist to get early access.

Skills, proven.

If You Installed One: Treat It as an Incident, Not Just a Flag

If you already ran the skill, the clock is the threat. An approved skill executes with full local user privileges and minimal interactive confirmation, so by the time you suspect something, credentials, files, and shell access may already be exposed.

OWASP's incident response checklist for malicious skills treats this as a live incident rather than a cleanup task, with six steps in order:

  • Isolate affected agents so the skill cannot keep calling out or acting.
  • Revoke compromised credentials — rotate keys, tokens, and SSH access the agent could reach.
  • Scan for lateral movement across other agents, repos, and machines.
  • Notify the skill registry hosting the package.
  • Update detection signatures so your scanners catch the same pattern again.
  • Review installation approval processes to close the gap that let it in.

Speed matters because the payloads are built to persist quietly. In the January 2026 ClawHavoc campaign, 1,184 malicious skills across 12 publisher accounts shared a single command-and-control IP, and five of the seven most-downloaded ClawHub skills at peak infection were confirmed malware. A separate scan of 3,984 skills found 13.4% carried at least one critical issue, and eight malicious skills were still live on ClawHub at publication — meaning your report may be the only signal that closes the gap.

That consent gap is the core problem: you approve a skill once, and it inherits everything your user account can do. Behavioral verification of 98,380 skills confirmed 157 malicious packages, and 93.6% were removed within 30 days of responsible disclosure — so reporting to the registry works, but only after you have contained the damage locally.

The durable fix is upstream: install from directories that pin every version to a commit SHA and security-scan before listing. SkillzBench is building exactly that — a free, independent directory of AI agent skills with a free MCP connector, so you choose which skills each agent sees instead of granting blanket trust.

Prevention Beats Reporting: Choosing Skills You Can Trust

Here's the uncomfortable math: even though responsible disclosure works — behavioral research found that 93.6% of confirmed malicious skills were removed within 30 days of being reported — the reporting process still leaves you exposed in the meantime. And with daily skill submissions jumping from under 50 to over 500 in a matter of weeks, Snyk researchers documented eight malicious skills still live on ClawHub at the time of publication.

That gap between "reported" and "removed" is why the smartest move is the one you make before installing anything. Reporting is reactive; selection is proactive. Given that an analysis of 31,132 skills found 26.1% carry at least one vulnerability, and that registries largely crawl public repos without mandatory security review, choosing a pre-vetted skill beats auditing a raw marketplace install every time.

What does "pre-vetted" actually mean in practice? Look for these signals before you install:

  • Independent security scanning — not just the publisher's word. OWASP warns that "a signature proves authorship, not safety: a verified publisher can still ship malicious content."
  • Pinned versions tied to a specific commit SHA, so the code you reviewed is the code you run — not whatever quietly ships next.
  • Sandbox-tested behavior, since static review alone "could not distinguish malice from mistakes," per the behavioral verification study.
  • Transparent scoring that separates measured performance from ratings, so money and marketing never touch the numbers.

This is exactly the gap SkillzBench is being built to close. It's a free, independent directory of agent skills where every skill is security-scanned, every version is pinned to a commit SHA, and every skill is benchmarked in a sandbox — with and without the skill — so you can see the actual Lift in percentage points before installing anything. A free MCP connector then lets your agent see only the skills you've explicitly chosen. Everything stays free; the scores stay independent.

The bottom line: reporting a malicious skill is a skill worth having, but the 93.6% removal rate only helps people who noticed something was wrong in the first place. Install skills that have already been verified, and you spend less time filing reports and more time getting real work done.

Skills, proven. Join the free SkillzBench waitlist and be first in line when the directory, benchmarks, and MCP connector go live.

Frequently Asked Questions

Where do I actually report a malicious AI agent skill?
There's no universal reporting portal — you report through whichever platform hosts the skill. Use the registry's flag or abuse-report mechanism (e.g., ClawHub), GitHub's abuse reporting channel for repo-hosted skills, or the platform's security contact for managed agents. Anthropic, for example, states it is working through triage and responsible disclosure with maintainers for vulnerabilities found in open-source codebases.
Does reporting a malicious skill actually get it removed?
Yes — reporting demonstrably works. When researchers responsibly disclosed confirmed malicious skills to registry maintainers, 93.6% were removed within 30 days. The problem isn't that registries ignore reports; it's that not enough users file them, which is why OWASP formally assigns users the duty to report suspicious activity.
What evidence should I include when I file a report?
Cite specific indicators rather than vague suspicions. Per OWASP's Agentic Skills Top 10, strong evidence includes base64-encoded payloads in YAML comments, downloads from non-HTTPS URLs, typosquatting of popular service names, excessive permission requests, and behavioral signs like unusual network connections or modifications to memory files such as SOUL.md or MEMORY.md.
How can I tell if a skill is actually malicious versus just buggy?
A skill is malicious only when behaviors like credential harvesting or data exfiltration indicate intentional abuse, not an incidental bug. Roughly 26% of analyzed skills carry vulnerabilities, but only 5.2% show patterns strongly suggesting malicious intent. Run static analysis (review SKILL.md, check for obfuscated code) plus dynamic analysis in an isolated sandbox before filing — report broken skills as feedback, not security incidents.
I already installed a suspicious skill — what should I do first?
Treat it as a live incident, not just a flag, because an approved skill runs with full local user privileges and may already have persistent access. Follow OWASP's six-step checklist: isolate affected agents, revoke compromised credentials, scan for lateral movement, notify the registry, update detection signatures, and review your approval processes. Notifying the registry is a formal step — your report helps close the gap for everyone else.
Does a verified publisher or signature mean a skill is safe?
No — a signature proves authorship, not safety. OWASP warns that a verified publisher can still ship malicious content, and one actor using templated brand impersonation accounted for 54.1% of confirmed malicious cases. To reduce risk before installing, use pre-vetted sources — SkillzBench is building a free directory that security-scans every skill, pins each version to a commit SHA, and sandbox-benchmarks behavior before listing.

Your Report Could Be the Reason a Malicious Skill Disappears

The evidence is clear: reporting malicious skills isn't just civic duty — it works. When researchers responsibly disclosed confirmed malicious skills, 93.6% were removed within 30 days. But with 26% of skills carrying vulnerabilities and registries doing little vetting, the smartest strategy is the one you make before installing: verify what a skill does in a sandbox, pin versions to specific commits, and treat any installed malicious skill as a live incident — isolate agents, rotate credentials, then notify the registry. Your next step is simple. Bookmark OWASP's Agentic Skills Top 10 indicators, know your registry's reporting channel, and review the skills your agents already have installed. And when you want skills that arrive pre-scanned, version-pinned, and benchmarked for real Lift, SkillzBench is building exactly that — a free, independent directory plus a free MCP connector so your agents only see the skills you trust. Join the waitlist at skillzbench.com. Skills, proven.

How to Report a Malicious AI Agent Skill (Step-by-Step) · SkillzBench