How do I install the Web Dependency Confusion skill?

Run npx skillmds@latest add noorqureshi/web-dependency-confusion in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Web Dependency Confusion safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Web Dependency Confusion?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Web Dependency Confusion free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Web Dependency Confusion?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Web Dependency Confusion by noorqureshi

Name: Web Dependency Confusion
Author: NoorQureshi

Web Dependency Confusion

Dependency confusion / substitution — publish a malicious public package matching an internal name so build systems pull yours. Load on leaked internal package names (npm/PyPI/RubyGems/Maven), package.json/requirements with unknown deps, or private-registry setups. Signals: @scope/internal packages, non-public dep names in manifests, .npmrc/registry config leaks.

NoorQureshi Updated Sep 17, 2026

File contents

Dependency confusion

When it applies

The target builds software using internal package names that aren't published publicly, on an ecosystem (npm, PyPI, RubyGems, Maven, NuGet) where a public registry is also consulted. If you can learn an internal name and publish it publicly, their resolver may fetch your package → RCE in their build/CI.

Why it works

Many package managers, misconfigured, prefer the highest version across all configured registries — public included. Publishing internal-lib@99.0.0 to the public registry can outrank the private internal-lib@1.2.3, so builds pull and execute your code (install scripts run automatically).

Method

Harvest internal names: leaked package.json/requirements.txt/pom.xml, source maps and JS bundles (→ recon-js-analysis), error messages, public repos, .npmrc/registry config.
Confirm the name is unclaimed on the public registry (npm/PyPI/etc.).
Publish a benign PoC package under that exact name with a high version, whose install/postinstall step makes an OOB callback (DNS/HTTP to your collaborator) including hostname/user — no destructive payload. This proves execution if their build pulls it.
Wait for the callback from their build/CI environment → confirms confusion.
Scoped packages: @company/pkg on npm needs the scope unclaimed; note the config that would prevent it.

Gotchas

Keep the payload benign and identifiable (your marker only) — you're proving exec, not attacking. Mind program RoE (many bug-bounty programs have specific rules for this).
Proper configs (scoped registries, --registry pinning, namespace ownership) prevent it — the finding is the missing control.
Take down the package after reporting.

Verify success

An OOB callback from the target's build/CI proving your public package was resolved and its code executed.

References

Alex Birsan "Dependency Confusion"; npm/PyPI scoping & registry-pinning docs.

---name: web-dependency-confusiondescription: Dependency confusion / substitution — publish a malicious public package matching an internal name so build systems pull yours. Load on leaked internal package names (npm/PyPI/RubyGems/Maven), package.json/requirements with unknown deps, or private-registry setups. Signals: @scope/internal packages, non-public dep names in manifests, .npmrc/registry config leaks.---# Dependency confusion## When it appliesThe target builds software using **internal package names** that aren't published publicly, on anecosystem (npm, PyPI, RubyGems, Maven, NuGet) where a public registry is also consulted. If you canlearn an internal name and publish it publicly, their resolver may fetch **your** package → RCE in their build/CI.## Why it worksMany package managers, misconfigured, prefer the *highest version* across all configured registries— public included. Publishing `internal-lib@99.0.0` to the public registry can outrank the private`internal-lib@1.2.3`, so builds pull and execute your code (install scripts run automatically).## Method1. **Harvest internal names**: leaked `package.json`/`requirements.txt`/`pom.xml`, source maps and JS bundles (→ `recon-js-analysis`), error messages, public repos, `.npmrc`/registry config.2. **Confirm the name is unclaimed** on the public registry (npm/PyPI/etc.).3. **Publish a benign PoC package** under that exact name with a high version, whose install/postinstall step makes an **OOB callback** (DNS/HTTP to your collaborator) including hostname/user — *no destructive payload*. This proves execution if their build pulls it.4. **Wait for the callback** from their build/CI environment → confirms confusion.5. **Scoped packages**: `@company/pkg` on npm needs the scope unclaimed; note the config that would prevent it.## Gotchas- Keep the payload benign and identifiable (your marker only) — you're proving exec, not attacking. Mind program RoE (many bug-bounty programs have specific rules for this).- Proper configs (scoped registries, `--registry` pinning, namespace ownership) prevent it — the finding is the *missing* control.- Take down the package after reporting.## Verify successAn OOB callback from the target's build/CI proving your public package was resolved and its code executed.## ReferencesAlex Birsan "Dependency Confusion"; npm/PyPI scoping & registry-pinning docs.

Frequently asked questions