T08 · Insecure Dependencies
- Location
package-lock.json:7- Finding
Dependency Lockfile Contains Undeclared and Unused Dependency Trees
- Content
View full analysis
Vulnerability Details
File Location:
package-lock.json, lines 7-18; inconsistent withpackage.json, lines 11-13
Vulnerability Type: Supply-chain exposure caused by inconsistent dependency manifests
Risk Level: LowThe root entry in
package-lock.jsondeclares four direct dependencies:json "": { "name": "youtube-transcript", "version": "1.0.0", "license": "ISC", "dependencies": { "@distube/ytdl-core": "^4.16.12", "xml2js": "^0.6.2", "youtube-transcript": "^1.3.0", "youtubei.js": "^16.0.1" } },However,
package.jsondeclares only one dependency:json "dependencies": { "xml2js": "^0.6.2" },The executable in
transcript.jsuses only Node.js built-in modules and does not import any of the packages listed above. The three additional direct dependency trees in the lockfile—@distube/ytdl-core,youtube-transcript, andyoutubei.js—are therefore undeclared and unused by the reviewed implementation.Technical Analysis
A lockfile is part of the trusted software supply chain. Retaining dependencies that are absent from the authoritative package manifest obscures the intended dependency set and can cause environment-dependent installation behavior. Package managers or automated tooling that directly honors or analyzes the stale lockfile may retrieve substantially more third-party code than the application requires.
In particular,
@distube/ytdl-coreintroduces several transitive networking, proxy, cookie, parser, and HTTP client packages. This unnecessarily expands the number of external maintainers and packages that must remain uncompromised. Although no package in the supplied lockfile was confirmed to be malicious, the inconsistency creates avoidable supply-chain exposure and makes dependency review less reliable.The lockfile also records packages such as
@distube/ytdl-coreandundicithat require Node.js 20.18.1 or later, whi ...[truncated 1560 chars]- Remediation
View remediation
Remediation Suggestions
- Delete
package-lock.jsonand regenerate it from the authoritativepackage.jsonusing a clean, trusted npm environment:bash rm -rf node_modules package-lock.json npm install - Verify that the regenerated root dependency entry contains only dependencies intentionally required by the application.
- Remove
xml2jsas well if it is not planned for use, because the currenttranscript.jsimplementation does not import it. - Commit
package.jsonandpackage-lock.jsontogether and require lockfile consistency checks in CI, such as a cleannpm civalidation. - Run dependency auditing and provenance checks after regeneration, and review any package that introduces lifecycle scripts.
- Align the declared Node.js engine with the actual dependency graph and test the minimum supported Node.js version in CI.
- Consider automated dependency review that rejects unexplained additions to the root lockfile dependency set.
- Delete
