SkillJacking: Hijacking Abandoned Skill Dependencies to Take Over AI Agents
What happened
SkillJacking is a supply-chain attack that takes over the abandoned dependencies an AI agent skill relies on. Rather than publishing a new malicious skill and hoping it clears review, the attacker captures a piece of infrastructure that an existing, already-trusted skill points at - a source repository, a package name, a linked domain, or a cloud subdomain. Once that resource is under attacker control, the code that thousands of agent installations fetch or reference is attacker-controlled too. The critical property is that this happens without updating the skill itself: the skill entry, its metadata, and its install count all look exactly as they did the day it was approved.
Agent skills are reusable capability packages - markdown instructions plus code - that load into an AI agent and execute with the agent's full permissions across platforms like OpenClaw, Claude Code, Cursor, and VS Code. That execution model is what makes SkillJacking dangerous: capturing one abandoned dependency can hand an attacker code execution inside every agent that installed the depending skill. For the fundamentals of how skills work and why they carry the agent's authority, see the OWASP Agentic Skills Top 10 guide, where this maps to the supply-chain compromise category (AST02).
The four takeover vectors
SkillJacking is not one trick. It is a family of takeovers that all exploit the same weakness: a skill references an external resource that can quietly change ownership. Researchers documented four distinct vectors.
| Vector | How it works | Example |
|---|---|---|
| GitHub account hijacking | When a developer's GitHub account is deleted, GitHub releases the username for re-registration. An attacker recreates the account and repository under the same name and controls the code distributed from it. | A skill that fetches code from a deleted creator's repo now pulls attacker code from the recreated repo. |
| Package takeovers | A skill references a package name that was never actually published or is no longer maintained. The attacker registers or claims that name and publishes malicious code under it. | A skill lists a dependency that does not exist in the registry; the attacker publishes it. |
| Domain takeovers | A skill links to a domain that has since expired. The attacker re-registers the domain and serves whatever content or code the skill trusted it to provide. | A skill pulls configuration or a helper script from an expired domain the attacker now owns. |
| Cloud app hijacking | An abandoned cloud subdomain (for example a Vercel deployment) becomes re-claimable. The attacker claims the dangling subdomain and controls the endpoint the skill talks to. | A skill calls an old Vercel app URL that has been released and re-claimed by the attacker. |
Every vector produces the same outcome from the agent's point of view: a resource it was told to trust is now serving code or instructions chosen by someone else. Nothing in the skill's own definition looks different.
The proof of concept: seedance2-api
The researchers demonstrated the GitHub account vector against a real skill. The seedance2-api skill had 11,483 installations. Its original creator's GitHub account, hexiaochun, had been deleted - which meant GitHub had released the username back into the pool. The researchers re-registered hexiaochun, recreated the repository the skill depended on, and thereby gained full control over every agent that installs the skill. From that position they demonstrated access to credentials and environment variables inside the agents that pulled the code.
This is the whole attack in one example. No malicious skill was submitted. No review gate was tricked. A popular, legitimate skill simply pointed at an abandoned account, and re-registering that account was enough to inherit its blast radius. The credentials and environment variables reachable from inside an agent are exactly the high-value targets an attacker wants, which is why skill supply-chain compromise sits alongside the broader patterns in the AI supply chain attacks defenders guide.
The scale of the exposure
The seedance2-api case is not an outlier. Across skill registries, researchers found nearly 1,000 skills built on hijackable dependencies, exposing roughly 134,000 agents to takeover. That is the shape of a supply-chain problem rather than a single vulnerable product: a large population of skills, each trusting external infrastructure that can lapse, and a downstream fleet of agents that inherit whatever those dependencies serve.
There is no CVE for SkillJacking and no version to upgrade to, because the weakness is not in any one skill's code - it is in the assumption that a dependency which was safe at approval time stays under the same ownership forever. That assumption is what a security program has to stop making.
Why point-in-time review cannot catch this
Most skill governance today is a submission gate: a skill is reviewed once, approved, and then treated as trusted indefinitely. SkillJacking is engineered to defeat exactly that model. At approval time the dependency is benign - the GitHub account is active, the package is unclaimed but harmless, the domain resolves to the real owner. The takeover happens *after* approval, when ownership silently transfers. A gate that only fires at submission has no event to react to, because from its perspective nothing about the skill ever changed.
This is the same lesson the endpoint community learned about shadow AI on the endpoint: an artifact that is installed once and never re-examined becomes a standing liability. The defensive posture has to shift from one-time approval to continuous re-vetting of both the skill and every external resource it depends on.
How Anomity surfaces and governs it
Anomity treats skills as one of the eight AI artifact types its lightweight, unprivileged Endpoint Sensor discovers and inventories on every managed endpoint, alongside AI agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. That inventory is the prerequisite SkillJacking makes unavoidable: you cannot re-check the dependencies of skills you have never enumerated. For each skill Anomity records what is installed and where, and sends metadata only over HTTPS - never source code, never prompts - with secrets redacted on the endpoint.
Because Anomity maintains a queryable 90-day audit trail of every added, removed, and modified artifact, a skill or dependency that changes underneath a stable name becomes an observable event rather than a silent substitution. Continuous policy evaluation means high-install skills that reference individual GitHub accounts, unpublished packages, or aging domains can be flagged for the continuous vetting this attack demands. And on agents that expose a hook, Anomity applies runtime governance - returning allow, deny, or log on each tool call before it runs - so even a hijacked dependency that tries to read environment variables or reach out to attacker infrastructure is evaluated against policy first, with violations routed to your SIEM, Slack, email, and Jira.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Build an inventory of every installed skill and the external dependencies each one references - repositories, package names, domains, and cloud subdomains.
- Treat vetting as continuous, not a one-time approval gate; re-check dependency ownership on an ongoing basis, following the skill vetting and approval playbook.
- Prioritize skills with high install counts, since those carry the largest blast radius if a dependency is captured.
- Flag any dependency on an individual developer's GitHub account, an unpublished or unclaimed package, or a domain nearing expiry.
- Apply dependency-chain security analysis so the transitive resources a skill trusts are examined, not just the skill entry itself.
- Enforce runtime governance so a hijacked dependency cannot exfiltrate credentials or environment variables without a policy decision first.
SkillJacking is a supply-chain attack with no patch, which means the only durable defense is visibility plus continuous re-evaluation. This advisory is part of our Agent Skills Security coverage; to see which skills across your fleet carry hijackable dependencies and what runtime governance would deny, book a 30-minute demo.
Frequently asked questions
What is SkillJacking?
SkillJacking is a supply-chain attack against AI agent skills. Instead of publishing a malicious skill, the attacker takes over an abandoned dependency that a legitimate, already-approved skill relies on - a GitHub account, an unpublished package, an expired domain, or an orphaned cloud subdomain. Because the code an agent fetches or references resolves to attacker-controlled infrastructure, the attacker gains control of what runs inside every agent that installs the skill, without ever modifying the skill.
Why is SkillJacking so hard to catch?
The skill entry never changes. It was vetted once, it looked fine, and its metadata still points at the same repository, package name, or domain it always did. The compromise happens underneath, when ownership of that external resource silently transfers to an attacker. A one-time approval gate sees nothing wrong, which is why point-in-time review is structurally blind to this class and continuous vetting is required.
What were the real-world numbers?
Researchers demonstrated the attack against the seedance2-api skill, which had 11,483 installations. When the original creator's GitHub account (hexiaochun) was deleted, they re-registered the released username, recreated the repository, and gained full control over every agent that installs the skill, demonstrating access to credentials and environment variables. Across registries they found nearly 1,000 skills built on hijackable dependencies, affecting roughly 134,000 agents.
Is there a CVE for SkillJacking?
No. SkillJacking is not a single product flaw with a fixed version; it is a systemic property of how agent skills reference external code and infrastructure. There is no patch to apply. The exposure is closed by inventorying which skills carry external dependencies, continuously re-checking whether those dependencies have changed ownership, and governing what the resulting code is allowed to do at runtime.
How is this different from a malicious skill?
A malicious skill ships bad code from day one and can be caught at submission. SkillJacking starts with a perfectly legitimate skill and weaponizes it later by capturing a dependency the skill trusts. The malicious-payload angle is covered in the advisory on malicious agent skills and hidden payloads; SkillJacking maps to the supply-chain compromise category (AST02) in the OWASP Agentic Skills Top 10.
How does Anomity help with SkillJacking?
Anomity inventories skills as one of the eight AI artifact types its Endpoint Sensor discovers, so you know exactly which skills are installed across the fleet and which carry external dependencies. Because it tracks every added, removed, and modified artifact in a queryable 90-day audit trail, a dependency or skill that changes underneath a stable name is surfaced rather than assumed safe. On agents that expose a hook, Anomity allows, denies, or logs each tool call before it runs, so hijacked skill code attempting to read credentials or reach out externally is evaluated against policy first.
What should we do right now?
Build an inventory of every installed skill and the external dependencies it references, then treat vetting as continuous rather than a one-time gate. Prioritize skills with high install counts and dependencies on individual GitHub accounts, unpublished packages, or aging domains. Pair that with runtime governance so that even a hijacked dependency cannot exfiltrate data or credentials without hitting a policy decision first.
