Block untrusted transitive dependencies (block-exotic-subdeps)

block-exotic-subdeps is a pnpm setting that refuses transitive dependencies pulled in from non-registry sources: git URLs, tarball or HTTP URLs, and local paths. A package you add yourself is your call; one smuggled deep into the tree from an arbitrary source is a far easier place to hide malicious code. This setting closes that door.

What it does

When you add a direct dependency, you can point it anywhere you like: the npm registry, a git repository, a tarball URL, a local path. That is a deliberate choice you make and can review. The risk is different for transitive dependencies: packages your dependencies pull in, often several levels deep, that you never named and rarely inspect.

pnpm calls a dependency that resolves from somewhere other than the npm registry an exotic dependency. Exotic sources include git repositories, direct URL links to tarballs, and local file paths. A direct exotic dependency is usually intentional. An exotic transitive dependency buried in the tree is a common way to smuggle code in from an arbitrary, unvetted source. The registry's publishing, versioning, and takedown controls never apply to it.

With block-exotic-subdeps turned on, pnpm refuses to resolve transitive dependencies from these exotic sources. Your direct dependencies may still use them; everything below the top level must come from a trusted source such as the configured registry.

Turn it on

This is a pnpm setting available in pnpm ≥ 10.26. Where it lives depends on your pnpm version. Use the rc form for older setups and the camelCase YAML key for newer ones.

pnpm ≤ 10 (rc file)

Add to your .npmrc:

block-exotic-subdeps=true

pnpm ≥ 11 (YAML)

Add to pnpm-workspace.yaml (per project) or your global config.yaml, using the camelCase key:

blockExoticSubdeps: true

Why it matters

In the May 2026 TanStack incident, the malicious code was wired in through a git-URL optionalDependency, exactly the kind of non-registry transitive source this setting restricts. block-exotic-subdeps would not have stopped every step of that attack on its own, but it directly narrows that class of source: a transitive dependency resolving from a git URL instead of the registry is precisely what it refuses to install.

Like a cooldown or install-script blocking, this is one layer. It restricts where deep dependencies may come from, not whether a registry-hosted package is safe. Pair it with the other settings in the hardening guide for defense in depth.

npm is moving the same way: npm v12 (expected in 2026) blocks git and remote-URL dependencies by default, with its allow-git and allow-remote settings defaulting to none. That is the same class of non-registry source this pnpm setting restricts.

Let DepsGuard set it up

DepsGuard detects your pnpm setup, checks whether block-exotic-subdeps is configured, and writes the right key into the right file for your version, with a diff preview and a backup before any change, so you can see exactly what it does before applying it.