pnpm 11.28.6
- Source
- https://github.com/pnpm/pnpm
- Tag scanned
v11.28.6- Directory
pnpm11/pnpm- Compared with
v11.28.5(0 signals introduced since)- Files
- 211 scanned, 10 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 21 info
- Scan time
- 13.4 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 20 of 20 warn and critical signals; 20 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-15 18:56
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
likely benign README instruction to install pnpm via curl piped to sh.
Reasoning
This is a documented install command in a README, shown for users to run. Piping a remote install script to sh is a known convention for pnpm's official installer. It is not hidden or obfuscated and does not run automatically.
-
likely benign README instruction to install pnpm via wget piped to sh.
Reasoning
Same as the curl variant: a documented wget install command in prose from the official pnpm site. Its presence in documentation is expected and it is not executed by the scanned code.
-
exec "$pnpm" "$@"likely benign Shell wrapper that execs the resolved pnpm binary with passed arguments.Reasoning
This is a pnpm launcher script. It resolves the real pnpm binary into $pnpm and then execs it with the user's arguments. A dynamic exec path is the expected behavior of a shim that delegates to another binary, and nothing in the snippet is obfuscated or fetches remote code.
-
exec "$pnpm" dlx "$@"likely benign Shell wrapper that execs pnpm dlx with passed arguments.Reasoning
Same launcher pattern as pn. It execs the resolved pnpm binary with the dlx subcommand and forwards arguments, which is the normal behavior of the pnpx alias.
-
exec "$pnpm" dlx "$@"likely benign Shell wrapper that execs pnpm dlx with passed arguments.Reasoning
Identical to pnpx: a thin delegating shim that execs the resolved pnpm with dlx. Severity is critical only because of the dynamic exec path, which is a legitimate pattern here.
-
. const = awaitdismissed Test dynamically imports a fixture module by path.Reasoning
This is test code importing fixture modules from computed paths so the test can check that they export functions. The specifier is a local test fixture path, not attacker-controlled input at runtime.
-
. const = awaitdismissed Test dynamically imports a negative fixture module by path.Reasoning
Same pattern as the sibling finding: a test imports a local fixture from a computed path to verify its default export. This is ordinary test-harness behavior.
-
. const = awaitdismissed Test dynamically imports a fixture module by path.Reasoning
Test helper importing a positive fixture module from a path variable. Legitimate test code with no obfuscation or runtime-supplied untrusted specifier.
-
. . })dismissed Test imports a peer package.json to check its version.Reasoning
Test reads package.json of a peer dependency from a computed path to assert its version. The path comes from test setup, so this is benign.
-
const pkg = await . })dismissed Test imports the local package.json to check dependencies.Reasoning
Test imports the local package.json via path.resolve to assert on dependencies. A static, project-local path in a test file is normal.
-
const = await . })dismissed Test imports package.json to compare manifest contents.Reasoning
Test imports package.json from a resolved local path to compare against the initial manifest. Ordinary test assertion code.
-
.dismissed Test imports package.json to assert dependency values.Reasoning
Test imports the local package.json and checks the dependencies object. A path.resolve call on a fixed filename is benign.
-
const = await . // spec of linked package added to dependenciesdismissed Monorepo test imports package.json to check workspace dependencies.Reasoning
Monorepo test imports the workspace package.json from a resolved path to verify the workspace dependency spec. Standard test behavior.
-
const = await . // spec of linked package added to dependenciesdismissed Monorepo test imports package.json to verify linked dependencies.Reasoning
Same as the other monorepo import: a local package.json is loaded through path.resolve and compared against an expected dependency map.
-
. .dismissed Test imports project package.json files to verify updated dependencies.Reasoning
Recursive update test loads several project package.json files by resolved path to check updated dependency ranges. Benign test assertion code.
-
. . })dismissed Test imports more project package.json files to verify dependency ranges.Reasoning
Continuation of the same test: additional local package.json imports to check dependency ranges. No untrusted specifier or hidden loading behavior.
-
. . })likely benign Test helper dynamically imports a package.json fixture via path.resolve.Reasoning
Dynamic import with path.resolve of a fixed test fixture path inside a test file; no decoding or hidden behavior. Non-literal specifier is flagged by rule but clearly benign here.
-
const = await .likely benign Test dynamically imports a static args.json fixture.Reasoning
Dynamic import of a constant fixture path (project/args.json) within a test assertion block. Benign test code pattern.
-
const = await .likely benign Test dynamically imports a static args.json fixture.Reasoning
Dynamic import of a constant local fixture (args.json) in a test. No external input or execution of fetched code.
-
const = await .likely benign Test dynamically imports a static args.json fixture.Reasoning
Same pattern as other test fixture loads: constant path resolved and imported for assertion. Benign.
Reproduce This Scan
Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
&&