SkillJacking - 925 Skills Hijacked From Their Maintainers, Affecting 134K Agents

So, starting from the end: we hijacked the most popular video-generation skill on skills.sh, proved we could compromise every agent installing it, with no visible effect on the user:

This is a PoC built in our lab, demonstrating how the takeover could have been weaponized. No malicious content was ever pushed to the real, public skill.

Here's how we did it, and why the problem is much deeper than a single careless skill.

The seedance2-api case

Meet seedance2-api. Seedance is one of the top video-generation models around right now, and this skill wraps its API so an agent can generate video on command. No surprise it caught on: 11,483 installs, top ~3% of the marketplace, which makes it the first result when searching Seedance on skills.sh.

The skill is served and installed from a GitHub repo: github.com/hexiaochun/seedance2-api. Installing the skill from skills.sh using npx skills <name> pulls its files live from the source GitHub repo, so whoever owns that repo controls exactly what you download.

There's one problem though: the owner's account, hexiaochun, doesn't exist anymore. It was deleted - and the second it was, GitHub dropped the username straight back into the pool for anyone to grab. Anyone can register hexiaochun, recreate seedance2-api, and now they own the repo that 11,483 installs clone from.

No exploit, no zero-day - a few clicks, and a top marketplace skill is an attacker's to control.

So we took it. We registered the username, recreated the repo, and just like that, we can control what agents run: getting their cloud credentials, their .env, their identity. All of it is now one commit away. The listing on the marketplace doesn't change. The author keeps the stars, the trust, the installs. We just own everything that ships under that name.

To prove we control the content, we pushed one deliberately obviously malicious but harmless test, no attempt to hide it. Scanners flagged it, naturally. But the takeover itself, and the dead source that made it possible, tripped nothing at all. Just as we demonstrated in previous posts, we could have used the same techniques to make a malicious skill go unnoticed.

Call it collaboration. hexiaochun built the reputation, we'll handle the payload. In this Circus of Skills, there is no "your skill" or "my skill", there’s only -

One dead account? We found a graveyard

In our previous posts, we deep-dived into the risks of external dependencies and instructions for skills. We started by showing how a motivated attacker could create a malicious skill that slips past security scanners and gains credibility - which our brand-landingpage skill did on a live marketplace. Then, in the second post, we explored the phenomenon of skills that rely on sketchy, hard-to-vet dependencies - 12.4% of skills have an external dependency we found hard to trust, with no clear credible maintainer.

When talking about supply-chain risks, the first scenario that comes to mind is maintainers of installed packages breaking bad. But the thing is, they don't need to. They don't even need to stop maintaining. A rename, a deleted account, and suddenly the name is anyone's to claim, with everything that installs under it.

Open source, and the skills community built on it, runs on people who build and share for free. That's exactly what makes it powerful, and it's also why maintainers move on. A fun side project gets old, and one day it's abandoned. We've all been there. This is legitimate; nobody promised eternal maintenance. But it creates a real security concern: ^{an unmaintained project can be taken over by an attacker, handing him direct access to a large, trusting user base.} This isn't hypothetical - it's the same repo-jacking and expired-maintainer package hijack that supply-chain attackers have exploited for years. The only new part is the target.

So we went looking for how many other Seedances are out there - skills whose external dependencies are hijackable today. Not theoretical, claimable now. We sorted them into four families:

• GitHub takeovers. When a GitHub user is deleted or renamed, all* repos on that account become hijackable by anyone recreating the same username. (This is exactly what happened to hexiaochun.)
• Package takeovers. Skills regularly instruct agents to install packages. If those packages don't exist, an attacker creates them and gets instant code execution on every user who installs the skill.
• Domain takeovers. Skills sometimes reference dead links - expired or never-registered domains. Whoever registers them inherits automatic agent traffic and a platform to serve malicious instructions.
• Cloud app takeovers. Apps on hosting services like Vercel or Railway get dedicated subdomains (e.g. myapp.vercel.app). Delete the app, and an attacker can register the same name under the same service and take it over.

* GitHub does block re-creating previously very popular repositories, but the bar to qualify is high enough that most of the dangling repos we found weren't covered by it.

The part that should bother you: victims don't need to update their skill to be affected. ^{They just need to use it one more time}.

We hijacked as many as we could ourselves - and where platforms like GitHub throttle mass registration and we couldn't take them all, we grabbed the highest-impact ones first, the accounts, repos and packages behind the biggest install bases. The rest we reported to the relevant host to have them shut down at the source.

‍

Which actions should security teams take?

SkillJacking shows that even the most credible and popular skills are susceptible to supply chain attacks. A skill that was once legitimate and installed on tens of thousands of agents can be hijacked and weaponized overnight, compromising every agent that installs it.

Enterprises need to adopt new approaches to protect themselves from such supply chain attacks:

1. ^{Skills must be vetted continuously, not only when installed}. A skill that is clean when you approve it can turn hostile the moment an abandoned account, expired domain, or unclaimed package behind it is seized - without a single line of its code changing.
2. ^{Vetting has to cover a skill's dependencies, not just its content}. As recognized last week by OWASP top 10 for skills. A trusted skill is a promise about its author; it says nothing about the resources that author reached for. Every repo it clones, package it installs, and link it fetches is an equal path to compromise - and a content scan only captures a snapshot that is benign today and weaponizable once its source is taken over. What matters is whether each of those sources can be trusted over time.
3. ^{Enterprises need a plan for when a takeover happens, not just to prevent one}. That means detecting supply chain attacks as they emerge, locating every instance of an affected skill across every agent, triaging which of them were actually exposed, and revoking the skill everywhere at once - not chasing it down one machine at a time.

That’s why today we’re publicly launching Air's skills scanner, which detects supply chain attacks including SkillJacking. It scans not just a skill's internal content but its entire dependency chain, and the first aligned to the OWASP Top 10 risks for Agentic Skills.