T08 · Insecure Dependencies
- Location
SKILL.md:25- Finding
Unpinned External Skill Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 25-27
Vulnerability Type: Unpinned third-party Skill dependency
Risk Level: Mediumbash clawhub install bilibili-auto-transcriptTechnical Analysis
The deprecated Skill directs users to install an externally maintained replacement using only its mutable package name. The installation command does not specify an audited version, immutable digest, integrity hash, or verified artifact.
The replacement package is not included in this project, so its instructions, scripts, permissions, and transitive dependencies cannot be audited from the available source. If the registry entry or publisher account is compromised, the same command could resolve to modified content after this Skill has been reviewed. This creates a third-party supply-chain trust boundary and matches
T08: Insecure Dependencies.The inspected file does not automatically execute the command; exploitation requires a user or agent to follow the documented migration instruction.
Attack Path
- An attacker compromises the replacement package, its publisher account, or the package distribution infrastructure.
- The attacker publishes a malicious release under the existing
bilibili-auto-transcriptpackage name. - A user follows the unpinned installation instruction in
SKILL.md. - The package manager resolves and installs the attacker-controlled release.
- Any malicious Skill instructions or executable components supplied by that release run when installed or invoked, subject to the installer and agent's available permissions.
Impact Assessment
Successful exploitation could allow attacker-controlled Skill content to operate with the permissions granted to the package installer or agent runtime. Depending on the replacement package's installation behavior and runtime capabilities, the scope could include modification of agent behavior, access to data available to the ag ...[truncated 360 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the replacement to a specifically audited version rather than resolving the latest release by package name.
- Require and verify an immutable package digest or cryptographic integrity hash before installation.
- Document the expected publisher identity and use registry signature verification where supported.
- Audit the replacement package, including its Skill instructions, scripts, installation hooks, requested permissions, and transitive dependencies.
- Prefer vendoring the reviewed replacement artifact or linking to immutable source and release records.
- Run installation and initial validation in a sandbox with minimal filesystem, network, credential, and tool permissions.
- Avoid claiming that the old package will be overwritten safely unless the replacement process and affected files have been independently verified.
