The Pipeline Is the Attack: AST02 Skill Supply Chain Compromise, Explained

In June 2026, Trail of Bits published a study with a title that said everything: “The Sorry State of Skill Distribution.” The researchers had set out to test whether marketplace scanners added meaningful security — and they bypassed every one they tested. Three of their four malicious test skills took less than an hour to build. Their conclusion was not “add more scanning.” It was that the distribution layer itself is broken: marketplace-run scanning, publisher vetting affected only at publish time, and no mechanism for skills to carry verifiable provenance from author to agent.

This is the second deep dive in our series on the OWASP Agentic Skills Top 10 — the hub is here and the previous part, AST01 on malicious skills, is here. AST02 shifts the frame: not “this skill is bad” but “the pipeline that delivered it is exploitable.” We’ll cover what the distribution layer actually looks like today, the four attack scenarios the OWASP document catalogs, and the provenance-and-pinning controls that make the pipeline tamper-evident.

What the distribution layer looks like today

Every skill an agent can load took a path through some subset of: a developer’s machine, a Git repository, a marketplace or registry (ClawHub, skills.sh, a platform store), and an installer. At the time of the January 2026 ClawHavoc campaign, the whole path was frictionless by design:

• Publishing to ClawHub required a SKILL.md and a one-week-old GitHub account. No signing, no review, no provenance. The attack cost was twelve fresh accounts — cheap for 1,184 malicious listings.
• Registry policies run ahead of security engineering. “Ship-first, secure-later” is the business model of every emerging marketplace; vetting arrives after the incident, if at all.
• Multiple registries don’t share intelligence. Snyk observed the same actors (publisher names zaycv, moonshine-100rze) publishing on both ClawHub and skills.sh — a skill flagged on one registry simply reappears on the other (see AST10 for where that intersects cross-platform reuse).

The structure mirrors npm and PyPI circa 2015 — same dynamics, same rush — with one big exception: the ecosystem already knows how this movie ends, and the OWASP controls borrow exactly the scars npm earned.

The four attack scenarios

1. Registry flooding

How it works: publish masses of look-alike names — typosquats, brand clones, variations — so that search and autocomplete route a meaningful share of installs to attacker-controlled packages. The registry becomes the attack surface itself: you’re not targeting one victim, you’re casting a dragnet over everyone who searches.

Example: ClawHavoc operated exactly this way: 1,184 skills whose names rode on legitimate brands’ trust (gogle-workspace, clawhud, yutube-dl-core). Enough installs landed on the fakes that five of ClawHub’s top seven downloads were malware at peak.

2. Dependency confusion

How it works: the skill looks clean — SKILL.md passes review, helper scripts read harmlessly — but it declares a dependency on a package name that doesn’t exist publicly, or typosquats a real one. When the installer resolves that nested package.json or requirements.txt, it pulls the attacker’s payload. The skill is the delivery envelope; the dependency is the bomb.

Example: ClawHavoc’s staged-loader technique: the published skill contained nothing malicious, and the second-stage Atomic Stealer download triggered during dependency installation — after review, before detection. The same pattern is why the AST01 mitigation list treats dependency-install as a sandboxing boundary in its own right.

3. Configuration hijacking (execute-on-clone)

How it works: agent platforms read project-local config files that support hooks — and hooks are code execution. A malicious repository carries an innocently-named .claude/settings.json (or equivalent) with a hook that runs when the project is opened. Clone and open: execution. No install step, no marketplace involved at all.

Example: Check Point’s 2026 research “Caught in the Hook” documented RCE and API-token exfiltration through Claude Code project files — users were compromised by the ordinary act of cloning and opening a repo, before any dialog appeared. CVE-2025-59536 and CVE-2026-21852 formalized the class (each scoring high on CVSS): hooks in project config execute with the agent’s privileges, and repositories are untrusted input.

4. Maintainer / publisher takeover

How it works: don’t attack the pipeline; attack the trusted node in it. Compromise a popular skill’s maintainer account — credential theft, session hijack, social-engineered ownership transfer — and push a “patch” through an established reputation. All downstream installers accept it because the publisher identity, the thing they actually verify, hasn’t changed.

Example: this is the event-stream of the skill world, and it’s the scenario that exposes the core gap: today’s marketplaces bind trust to an account, not to a cryptographic key the account can’t silently swap. A taken-over account inherits every trust signal the marketplace ever attached to it — download counts, tenure, ratings — because those signals live in the registry’s database, not in anything the publisher can prove.

Why the scanners didn’t save us

Trail of Bits’ June 2026 study is the controlled experiment. Their malicious test skills were not sophisticated operations:

• Every marketplace scanner they tested was bypassed.
• Three of four malicious skills took less than an hour to build from idea to published.
• The same few evasion tricks worked everywhere: natural-language instruction payloads (nothing for a code scanner to see), Unicode-hidden directives, and payloads staged in dependency-install hooks.

Their recommendation set is the OWASP mitigation list in miniature: curated marketplaces over open ones, immutable pinning, and publisher-controlled provenance — trust flowing from keys, not accounts.

Controls that actually work

1. Provenance and signing as a publish requirement. Ed25519 signatures over a canonical digest of SKILL.md plus declared resources, public keys resolved from a publisher-keyed trust store. This converts “who published this” from a registry database field into a cryptographic fact the account can’t be social-engineered out of. It directly kills maintainer-takeover-as-attack, because a takeover without the key produces an unverifiable skill.
2. Immutable content pinning. Pin installed skills to sha256 digests (the --hash=sha256: model from pip), never floating versions. Combined with signing, any change to a deployed skill — update, rug-pull, server-side swap — becomes a visible cryptographic mismatch instead of a silent drift.
3. Registry transparency-log lookups. A public, append-only log of all publishes (the Certificate Transparency model) lets any agent or enterprise verify a skill’s history: first-seen time, publisher key continuity, version chain. Flooding attacks become statistically visible — twelve accounts publishing 1,184 near-identical skills is a pattern a transparency log makes undeniable.
4. SKILL.md integrity checks independent of the marketplace. The document you reviewed is the document that runs: hash SKILL.md at review time, pin that hash, verify at load time. This closes the gap between marketplace-displayed content and delivered content, and it’s the same control that underpins AST05’s external-instruction defenses.
5. Treat repo config as untrusted code. The execute-on-clone class (CVE-2025-59536, CVE-2026-21852) dies when platforms gate hooks behind explicit per-project approval and enterprises treat cloned repositories like downloaded executables — because functionally, they are.
6. Curated internal registries for enterprise. The Trail of Bits recommendation: an internal registry that mirrors, reviews, re-signs, and pins external skills. Agents install only from there. Attackers can’t flood a registry they can’t publish to.

Common mistakes when defending AST02

• Confusing scanner coverage with pipeline integrity. Scanners evaluate content; AST02 is about provenance. A clean scan of a taken-over publisher’s malicious update is a true negative delivered through a compromised channel — the content check can’t catch what the trust model gave a pass. (See AST08 for the scanner side.)
• Trusting download counts and tenure. Every reputation signal in a marketplace database is either gameable (flooding, star-farming) or inheritable by an account thief. Signals that live in the registry are signals an attacker with the account owns too.
• Pinning versions but not content. Version pinning prevents upgrade attacks but not registry-side substitution within a version. Content-hash pinning prevents both.
• Forgetting the dependency layer is code. Reviewing a skill’s scripts while letting its requirements.txt resolve freely at install time is reviewing the envelope and ignoring the letter.

Framework references

• MAESTRO: L7 (Ecosystem & Distribution) — same layer as AST01, which is why the two risks share most controls and differ mainly in where the attacker sits: AST01 attacks publish content, AST02 attacks the channel and its trust nodes.
• CWE: CWE-494 (Download of Code Without Integrity Check) is the canonical mapping; the config-hijack scenario family also relates to CWE-94 (Code Injection).
• In this series: the downstream consequences of running what arrived are AST03 (permissions) and the scanner-evasion side of Trail of Bits’ findings is AST08 (scanning).

AST02 in ten lines

1. AST02 attacks the pipeline, not the payload: flooding, confusion, config hijack, takeover.
2. ClawHub at ClawHavoc time: SKILL.md + 1-week-old GitHub account = publisher. No signing.
3. Dependency confusion: nested package.json/requirements.txt resolve attacker payloads post-review.
4. CVE-2025-59536 / CVE-2026-21852: hooks in repo config = RCE on clone-open via Claude Code.
5. Maintainer takeover inherits every registry-stored trust signal — accounts aren’t keys.
6. Same actors publish on ClawHub and skills.sh; registries share no threat intelligence.
7. Trail of Bits Jun 2026: every scanner bypassed; 3-of-4 malicious skills built in under an hour.
8. Controls: Ed25519 provenance, sha256 content pinning, transparency logs, SKILL.md integrity.
9. Treat cloned repositories as executables; gate project hooks behind explicit approval.
10. Enterprise pattern: curated internal registry that mirrors, reviews, re-signs, and pins.

Next in this series: AST03 — Over-Privileged Skills, where the skill is neither malicious nor smuggled: it does exactly what it says, and that’s the problem. The permission-model gap, the literal DROP TABLE scenario, and what a workable skill manifest looks like.