T08 · Insecure Dependencies
- Location
SKILL.md:19- Finding
Unpinned Third-Party npm Package Installed Globally
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 19
Vulnerability Type: Supply-chain exposure through a mutable third-party dependency
Risk Level: MediumVulnerable Code:
bash # Requires todoist-ts-cli >= 0.2.0 (for --top / --order) npm install -g todoist-ts-cli@^0.2.0Technical Analysis
The installation command uses the mutable semantic-version range
^0.2.0. For a package below version 1.0.0, this permits npm to resolve a later compatible0.2.xrelease rather than an exact, previously audited artifact.The command also installs the package globally. npm packages can define lifecycle scripts that execute during installation with the privileges of the invoking user. Consequently, compromise of the package publisher, registry artifact, or a subsequently released compatible version could result in arbitrary local code execution. The skill does not provide a lockfile, package-integrity hash, verified provenance, or instructions to disable installation scripts.
This is a supply-chain weakness rather than evidence that the currently published dependency is malicious.
Attack Path
- An attacker compromises the npm publisher account or another part of the package publication process.
- The attacker publishes a malicious release accepted by the
^0.2.0range. - A user follows the documented global installation command.
- npm resolves and downloads the attacker-controlled compatible version.
- Malicious package code or an npm lifecycle script executes with the installing user's privileges.
- The package may then access user-readable data, credentials, and Todoist operations available through the configured token.
Impact Assessment
Successful exploitation could provide arbitrary code execution under the account running npm. The attacker could access or modify files available to that account, steal environment variables and credentials, or misuse the configured Todoist ...[truncated 201 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the dependency to an exact, reviewed version rather than using a caret range.
- Prefer a project-local, lockfile-backed installation over a global installation.
- Verify package provenance and registry ownership before recommending the dependency.
- Record and verify the package integrity hash in a lockfile.
- Audit package contents and lifecycle scripts before installation.
- Where compatible with the package, use
npm install --ignore-scriptsto prevent lifecycle-script execution. - Provide a controlled update process in which each new dependency version is reviewed before the pinned version changes.
