T08 · Insecure Dependencies
- Location
SKILL.md:5- Finding
Unpinned External Go Dependency Installed from a Mutable Version
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 5–13
Vulnerability Type: Unpinned third-party executable dependency
Risk Level: MediumVulnerable code snippet:
yaml metadata: {"clawdbot":{"emoji":"📰","requires":{"bins":["blogwatcher"]},"install":[{"id":"go","kind":"go","module":"github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest","bins":["blogwatcher"],"label":"Install blogwatcher (go)"}]}}markdown Install - Go: `go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest`Technical Analysis
The Skill directs the installation system and users to install
github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest. The@latestselector is mutable and resolves to whichever upstream version is considered latest at installation time. Consequently, the installed source is not necessarily the version reviewed when this Skill was published.This creates a supply-chain risk because a compromised upstream repository, maintainer account, module release process, or malicious future release could alter the executable delivered through these instructions. The project does not pin an immutable reviewed version or commit and does not specify an independent checksum or provenance-verification mechanism.
Attack Path
- An attacker compromises the upstream repository, a maintainer account, or its release process.
- The attacker publishes a malicious version that becomes the module version resolved by
@latest. - A user or automated Skill installer processes the installation metadata or follows the documented
go installcommand. - Go downloads and compiles the attacker-controlled source into the local
blogwatcherexecutable. - When the Skill or user invokes
blogwatcher, the malicious executable runs with the invoking user's privileges.
Impact Assessment
Successful exploitation could provide arbitrary code execution under the account that installs or invokes the ...[truncated 518 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace
@latestin both the installation metadata and documentation with a specific, reviewed semantic version, such as@vX.Y.Z. - For stronger immutability, pin a reviewed commit or otherwise ensure the selected version cannot be replaced in the trusted distribution channel.
- Keep the version in the metadata and human-readable installation instructions synchronized.
- Verify the selected release's source provenance and review upstream changes before upgrading.
- Where the distribution workflow permits it, validate release checksums or signed provenance and document the expected publisher and repository.
- Process dependency updates through an explicit review and testing workflow rather than automatically tracking the latest release.
- Replace
