T08 · Insecure Dependencies
- Location
SKILL.md:4- Finding
Unpinned Third-Party Executable Dependencies
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 4
Vulnerability Type: Unpinned third-party dependencies
Risk Level: MediumVulnerable Code
yaml metadata: {"openclaw":{"emoji":"📑","requires":{"bins":["mineru-open-api"]},"install":[{"id":"npm","kind":"node","package":"mineru-open-api","bins":["mineru-open-api"],"label":"Install via npm"},{"id":"uv","kind":"uv","package":"mineru-open-api","bins":["mineru-open-api"],"label":"Install via uv"},{"id":"go","kind":"go","package":"github.com/opendatalab/MinerU-Ecosystem/cli/mineru-open-api","bins":["mineru-open-api"],"label":"Install via go install","os":["darwin","linux"]}]}}Technical Analysis
The installation metadata identifies npm, uv, and Go packages without pinning an exact version or immutable source commit. Consequently, installation may resolve to a mutable current release rather than the specific dependency revision reviewed by the project author.
The project contains no lockfile, integrity checksum, vendored dependency source, or other mechanism that independently verifies the installed executable. Because
mineru-open-apiis subsequently invoked to process local documents, compromise of its package registry entry, source repository, maintainer account, or a future upstream release could introduce malicious code into the installation or runtime path.This finding does not establish that the current upstream package is malicious. It identifies a supply-chain weakness that permits the executable obtained during installation to differ from the version originally intended or reviewed.
Attack Path
- An attacker compromises an upstream package publication channel, repository, or authorized maintainer account.
- The attacker publishes a malicious release under the dependency name referenced in
SKILL.md. - A user or agent installs the dependency through the unpinned npm, uv, or Go installation option.
- The package manager resolves ...[truncated 793 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin each dependency to an exact, reviewed release instead of allowing installation of a mutable latest version.
- For the Go installation source, reference an immutable reviewed commit or exact module version.
- Supply and enforce package integrity hashes or equivalent provenance verification where supported.
- Add appropriate lockfiles or reproducible dependency manifests to the project.
- Verify that all referenced packages originate from the expected official publisher and repository.
- Review dependency source and release artifacts before updating pinned versions.
- Prefer signed releases and verified provenance attestations where available.
- Run installation and document conversion with least privilege in an isolated environment, without unnecessary credentials or filesystem access.
- Establish a controlled update process that performs security review and integrity verification before changing dependency pins.
