T08 · Insecure Dependencies
- Location
SKILL.md:164- Finding
Unpinned Third-Party Package Installation and Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:164-169; additional occurrences atSKILL.md:25,SKILL.md:44, andreferences/REFERENCE.md:323
Vulnerability Type: Insecure third-party dependency execution
Risk Level: Mediumbash bun add zod # runtime dependency bun add -d @types/node # dev dependency bun remove unused-pkg # remove bunx prettier --write . # run without installingTechnical Analysis
The Skill broadly recommends installing dependencies through
bun addand executing registry packages throughbunxwithout requiring exact versions, lockfile verification, package provenance checks, or explicit user approval.In particular,
bunxcan download and execute package-controlled code in the current project context. An unpinned package name may resolve to a subsequently compromised release, while a misspelled or attacker-influenced name may resolve to a typosquatted or dependency-confusion package. Such package code can inherit the agent process's filesystem, environment, subprocess, and network access.The documentation also notes Bun's automatic package installation behavior. Although this is legitimate Bun functionality, relying on automatic or ephemeral dependency resolution weakens reproducibility and expands the supply-chain attack surface beyond the minimum privileges needed for tasks that can be completed with Bun's built-in APIs.
Attack Path
- An attacker influences a package name through user-controlled instructions, repository content, or a typo resembling a legitimate package.
- The agent follows the Skill's general recommendation to invoke
bunx <pkg>orbun add <pkg>. - Bun resolves and downloads the package from the configured registry without a mandatory pinned version or provenance validation.
- The downloaded package's executable or package-controlled code runs in the project context.
- Malicious c ...[truncated 962 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit user approval before installing or executing any third-party package.
- Use verified package names and pin exact versions, including versions passed to
bunx. - Prefer committed and reviewed lockfiles, and use
bun cior an equivalent frozen-lockfile workflow in automated environments. - Validate package provenance, publisher identity, integrity metadata, and registry source before execution.
- Avoid constructing package names from untrusted user input or repository-controlled instructions.
- Prefer Bun's built-in functionality when it can satisfy the task without introducing a dependency.
- Run unavoidable third-party tools in a restricted environment with minimal filesystem access, sanitized environment variables, limited subprocess permissions, and constrained outbound network access.
- Document that ephemeral execution does not imply safety and that
bunxpackages execute with the invoking process's permissions.
