T08 · Insecure Dependencies
- Location
SKILL.md:14- Finding
Unpinned Third-Party CLI Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 14–17
Vulnerability Type: Unpinned and mutable third-party dependencies
Risk Level: MediumVulnerable Code
bash npm install -g mineru-open-api # or via Go (macOS/Linux): go install github.com/opendatalab/MinerU-Ecosystem/cli/mineru-open-api@latestTechnical Analysis
The documented installation commands retrieve and install third-party software without selecting a reviewed, immutable version. The Go command explicitly uses the mutable
@latestversion, while the npm command omits a version entirely and therefore resolves the package registry's current default release.The npm installation is global and may execute package lifecycle scripts during installation. The project provides no lockfile, checksum, signature verification, vendored implementation, or other mechanism that binds installation to the code reviewed during this audit. Consequently, the effective code installed by these commands can change after the Skill has been reviewed.
This creates a supply-chain risk if the upstream package, publisher account, package registry, release process, or referenced repository is compromised. There is no evidence in the audited file that the named package is currently malicious; the finding concerns the unsafe mutable dependency installation practice.
Attack Path
- An attacker compromises the upstream package publisher, repository, release pipeline, or registry account.
- The attacker publishes a malicious release under the expected package name or replaces the release resolved by
latest. - A user or agent follows the installation instructions in
SKILL.md. - The package manager retrieves the attacker-controlled mutable release.
- For npm, malicious lifecycle scripts may execute during installation; otherwise, the malicious code executes when
mineru-open-apiis invoked. - The payload operates with the privileges of the in ...[truncated 699 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin both installation methods to a specific, reviewed release rather than relying on an omitted version or
@latest. - For npm, document an exact version and, where feasible, use a lockfile and integrity metadata.
- For Go, replace
@latestwith a specific semantic version or reviewed immutable commit. - Publish expected checksums or signature-verification instructions for release artifacts.
- Avoid global installation where possible. Prefer a project-local dependency, isolated environment, or container running without elevated privileges.
- Disable npm lifecycle scripts during installation when the package does not require them, and verify functionality before recommending that configuration.
- Document the expected publisher, canonical source repository, audited version, and package provenance so users can detect typosquatting or publisher changes.
- Establish a controlled dependency-update process in which new releases are reviewed and their pinned versions and integrity values are updated explicitly.
- Pin both installation methods to a specific, reviewed release rather than relying on an omitted version or
