Clawing Out: The Skills Marketplace Just Inherited Its First Second-Degree Supply Chain Risk
Understanding second-order supply-chain risk in agent ecosystems: this is not just an OpenClaw issue - any system consuming agent skills may inherit the risk.
We identified an active malicious supply-chain campaign targeting agent skills, where attackers impersonated popular skills to distribute malware. This activity was responsibly disclosed and promptly taken down by the OpenClaw maintainer.
While examining the blast radius, we uncovered an additional systemic failure in how agent skill marketplaces interoperate. Skills removed from the primary marketplace continued to propagate through downstream registries and aggregators that automatically inherit and redistribute content from upstream sources. As a result, malicious skills remain discoverable and installable even after takedown.
The implication is severe: any agent that consumes skills - regardless of where it sources them from - can be exposed to malicious behavior. Once a skill enters the ecosystem, it can spread beyond its original marketplace and be picked up by other registries, tooling, or automation flows, putting all agents at risk, not just those using a specific platform.
Overview
The software supply chain risk presented by agentic tooling and skill ecosystem is seriously underestimated. As agentic tooling spreads, “skills” are becoming the default way to extend capabilities: install a skill, and your agent can now deploy infrastructure, query databases, message teammates, read email, triage tickets, or run commands. It’s convenient. It’s composable. It’s also a trust transfer.
But the trust model and supporting ecosystem is still very immature.
Recent research backs up what many practitioners have felt intuitively: skills marketplaces already contain a meaningful amount of risky content at scale. One large empirical study of agent skills across two major marketplaces found 26.1% of analyzed skills contained at least one vulnerability, spanning categories like prompt injection, data exfiltration, privilege escalation, and supply-chain risks.
That’s not a niche problem. That’s a systemic one. As the authors state:
“These results underscore the urgent need for capability-based permission manifests, mandatory pre-publication security scanning, and runtime sandboxing to secure this emerging ecosystem.”
A Live Example: When Agent Skills Become a Persistent Supply Chain Risk
This morning, we identified yet another active supply-chain campaign targeting ClawHub, the OpenClaw skill marketplace.
At least two users (@sakaen736jih and @moonshine-100rze) were uploading malicious skills impersonating popular, legitimate ones. Among the targeted skills (see complete list below) were: bird, agent-browser, auto-updater, coding-agent, nano-pdf, excel, moltbook, and more…
The campaign appears to be related to the ClawHavoc activity reported yesterday by Koi and OpenSourceMalware, with payloads delivering an Atomic macOS Stealer (AMOS) variant.
All malicious skill files exhibit the same characteristics: Description of the legitimate skill, followed by a note requiring windows users to download the OpenClawProvider package from an external source and Mac Users to pull the malicious payload using a based64 encoded command:
The malicious packages was were quickly removed from ClawHub by Peter Steinbergerand the users behind it were banned.
This isn’t the first malicious skill campaign we’ve seen, and it likely won’t be the last. But the interesting part here isn’t just the malicious campaign.
It’s what happened after some of these skills were identified and removed.
UPDATE: On February 5th, we’ve identified an additional batch of malicious skills with the same characteristics pushed by user @zaycv including whatsapp, blrd, youtubewatcher, and others (see complete list in the IoCs section).
First things first: what are agent skills?
Agent skills are bundles of instructions, scripts, and resources that agents can discover and use to perform tasks more accurately and efficiently.
“Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.”
At a structural level, a skill is typically a folder centered around a SKILL.md file. This file contains basic metadata (name and description, at minimum) longside natural-language instructions that tell the agent how to perform a specific task. Skills can also include additional scripts, templates, configuration files, and reference materials that the agent is expected to read and act upon.
Traditional dependency risk is already hard: transitive dependencies, maintainer compromise, typosquatting, social engineering, and the occasional “oops we shipped a credential”. Most security teams have at least some controls here (SCA, allowlists, pinned versions, artifact scanning, SBOMs).
Skills shift the ground under all of that.
A “skill” is often:
Instructions (natural language directives the model will follow)
This means you’re not just importing code - you’re importing behavior.
And it is behavior executed by a system that is:
Highly privileged (by design)
Non-deterministic and difficult to reason about end-to-end
Susceptible to persuasion and manipulation
In other words, skills are compound supply-chain risk with agentic risk.
Ok, now that we understand what Skills are, let’s get back to what we found…
Removal is Not Remediation: Downstream Skill Marketplaces Amplify Risk
In young ecosystems, people lean heavily on reputation signals like:
Download counts
Stars
A credible owner
But, as Jamieson O’Reilly demonstrated last week, early marketplace ecosystems repeatedly demonstrate how fragile and easy to spoof those signals are. By targeting the recent trending ClawHub marketplace (which had no static analysis, no behavioral restrictions, and no review process), he showed how trivial it can be to publish a backdoored skill, inflate popularity metrics, and get real users to run it, believing it’s legitimate.
The thing is, ClawHub is not the only place skills are distributed.
Several other registries and aggregators index skills automatically from external sources:
Some, crawl public GitHub repositories and ingest anything that looks like a skill.
Others pull directly from upstream repos and re-publish them under a different interface.
It turns out that skills that were flagged and removed from ClawHub’s UI continue to exist in upstream repositories - and are still being indexed, served, and installable through downstream marketplaces.
SkillsMP, which currently has over 145K skills, is a once such example. Let’s look at a concrete example - one of the malicious packages from the current campaign - bird-js. If we head over to it's relevant SkillsMP page, we can see a few (bad) things:
The author appears to be “OpenClaw”
Stars and forks were inherited from the upstream repository, lending false credibility
The displayed SKILL.md still contained the malicious payload, yet there is no other indication that this isn’t the legitimate bird skill.
So this malicious skill, that was already removed from ClawHub remains accessible through SkillsMP, inheriting credibility signals of the original skill, where only thorough inspection of the SKILL.md file could provide an indication that the skill is malicious.
Downstream marketplaces don’t just mirror content - they often introduce new installation paths.
In this case, users could still install malicious skills via:
Direct ZIP downloads
Package managers that clone upstream repositories
Tools that fetch skills from arbitrary remote sources without verification
Each additional path becomes another opportunity for silent compromise. Even when a marketplace removes a malicious skill from its UI, any system that blindly mirrors or indexes upstream sources can continue distributing it, without warning, attribution, or context.
Without built in mechanisms for vetting the content uploaded to the marketplace, skills can instruct the models using them to do anything.
If a malicious skill can persist after takedown, then “removal” is not a security control - it’s a notification.
What this means for you?
Skills Blur the Line Between “Code You Run” and “Text You Trust”
A lot of teams still treat skills as “just configuration” or “just prompts”, but in practice, skills behave like a hybrid of a package and a playbook:
A package because it ships artifacts that can execute code.
A playbook because it directs an agent to take actions.
This is why the risk is broader than a single file like SKILL.md. Any referenced file, template, auxiliary script, and even the markdown files themselves, become part of the agent’s effective instruction surface.
If your agent uses skills that reference additional files, then those files are also part of the trust chain:
Additional markdown rules
Configuration manifests
Package definitions
Tool wrappers and scripts
While a user might be satisfied by glancing over the “main” skill definition and making sure it looks legit, the agent will happily consume everything it can access.
Over time, the skill ecosystem and related marketplaces will mature and become more secure. We’re already seeing early steps in that direction - for example, ClawHub recently added GitHub user verification (including a minimum account age), along with reporting and moderation capabilities:
But attackers, aren’t waiting around. Multiple malicious skill campaigns targeting ClawHub were already identified, with hundreds of malicious skills making their way onto the platform.
These are the most common failure modes we are seeing:
1) Skill marketplace supply-chain attacks
Backdoored/Malicious skills
Typosquatting / impersonation (either to popular skills or the marketplaces themselves)
Malicious updates to popular or seemingly benign skills
2) Metadata manipulation and social engineering
Spoofing “Trust” signals such as download count, reviews or stars
Lookalike domains and endpoints used by skill scripts
3) Permission fatigue
Even if the agent prompts before actions, humans naturally become less vigilant in workflows where agents need constant permissions to be useful.
4) Indirect prompt injection through skill inputs
Skills often have access to external tools and consume external content: issues, docs, tickets, emails, chat messages, repos, and more. That content can contain instructions that influence the model’s behavior. As the UK NCSC has explicitly warned, prompt injection is fundamentally difficult to fully mitigate because models don’t reliably separate instructions from data.
That matters because skill ecosystems increase how often agents ingest untrusted content and how much authority they have when they do.
5) Secrets leakage as a default outcome
Skills often normalize passing credentials and tokens around in environment variables, tool config, files, and logs, often not in a secure manner.
Once you accept that “skills are behavior”, you should assume that any behavior you import may try to exfiltrate secrets, whether intentionally or accidentally.
6) Downstream propagation and stale trust
Like we saw in this case, even when a malicious skill is identified and removed from its original marketplace, it may continue to exist in: forked repositories, cached mirrors, or skill marketplaces.
Why this is different from a standard plugin or extension?
Agent skills don’t just extend software - they extend agency.
In computer-using agents, skills allow an agent to act directly in your environment: read your messages, use your credentials, interact with your browser, and execute actions on your behalf. The more capable the agent becomes, the more closely it mirrors a human operator.
That’s the appeal, as well as the risk.
Skills are how those agents learn what to do next. When you install a skill, you’re not adding a helper function; you’re expanding the set of things the agent is allowed to do in your environment. Over time, that means more credentials, more access, more automation, and more persistent context.
So when a skill goes wrong, the failure mode isn’t “bad code”. It’s an autonomous system exercising delegated authority with your access.
What we recommend doing right now?
For builders and individual users:
Treat third-party skills as untrusted code Read them before using! Read the referenced files too. Treat “instructions” as executable.
Assume popularity metrics can be gamed Download counts and stars are not security properties.
Use isolation by default Run skills in sandboxes, containers, or VMs, especially anything you didn’t write. Reduce filesystem and network reach as much as possible.
Use test credentials first If a skill needs OAuth or API keys, start with scoped test accounts. Treat first-run as staging.
Run automated scanning Static analysis isn’t sufficient, but it helps catch obvious badness quickly. Cisco’s open-source skill scanner is one example of tooling aimed at this category.
For security teams:
Inventory “skills” as a software supply-chain class Track and govern:
which skills are installed
where they came from
who approved them
what they can access
Enforce least privilege at the capability layer
Don’t only gate “the agent”, gate:
Tool invocation (what tools can be called)
Data access (what sources can be read)
Output channels (where data can be sent)
Secrets scope (which tokens can be used for what)
Aim to log skill-triggered actions as first-class events
Plan for revocation
Assume you’ll need to quickly disable a skill, rotate tokens or invalidate sessions.
Closing Thoughts
Supply-chain attacks aren’t new. Attackers have always followed the path of least resistance, and they always will.
The difference today is maturity. Traditional open-source ecosystems and package repositories have had years to absorb painful lessons, develop best practices, build tooling, and establish norms around trust, provenance, and response. None of that happened overnight, it was earned through repeated failures - and even now, successful attacks still happen.
The AI supply chain, by contrast, is still early and fragmented. It spans models, agents, skills, prompts, marketplaces, and social layers, but hasn’t yet had the time to develop comparable guardrails, frameworks, or shared security practices.
What recent campaigns show is not just that malicious skills exist, but that skill ecosystems behave like real supply chains, with the same problems and failure modes we’ve seen for years in traditional package ecosystems.
Once a malicious skill escapes into downstream indexes, mirrors, and automation tools, it stops being a single-platform issue. It becomes a distribution problem.
Layer on top of that AI-specific challenges like indirect prompt injection, delegated authority, opaque execution paths, and rapidly expanding attack surfaces, and the outcome is predictable - misconfigurations, fraud, vulnerabilities, and supply-chain attacks exploiting the immaturity of the entire AI ecosystem.
Security incidents targeting AI-based systems and the ecosystems around them aren’t an anomaly. They’re an inevitability until the security model catches up.
