T08 · Insecure Dependencies
- Location
SKILL.md:44- Finding
Unpinned and Inconsistent Remote Installation Sources
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:44;README.md:8;README.md:13
Vulnerability Type: Supply-chain exposure through mutable and inconsistent installation sources
Risk Level: MediumVulnerable Code
SKILL.md:44:bash openclaw install skill https://github.com/swimmingkiim/openclaw-skill-ai-news-oracleREADME.md:8:bash clawhub install modesty-ai-news-oracleREADME.md:13:bash git clone https://github.com/ModestyRichards/ai-news-oracle.gitTechnical Analysis
The installation instructions retrieve mutable Skill content without specifying an immutable commit hash, verified release artifact, checksum, or cryptographic signature. A later change to an upstream repository or registry package can therefore cause users to install content different from the artifact reviewed in this audit.
The documented sources are also inconsistent.
SKILL.mdidentifies and installs from theswimmingkiimGitHub account, whileREADME.mddirects manual installation fromModestyRichardsand registry installation throughmodesty-ai-news-oracle. The audited files provide no verification that these sources contain equivalent content or are controlled by the same trusted publisher.This is a supply-chain weakness rather than evidence that the currently audited two-file artifact contains an executable malicious payload. The risk arises when a user follows the installation instructions and trusts mutable, insufficiently authenticated upstream content.
Attack Path
- An attacker compromises, acquires, or otherwise gains publishing access to one of the documented GitHub repositories or the associated registry entry.
- The attacker modifies the remote Skill by adding malicious instructions, executable scripts, excessive permission requests, or credential-exfiltration behavior.
- A user follows one of the unpinned installation commands.
- The package manager o ...[truncated 973 chars]
- Remediation
View remediation
Remediation Suggestions
- Designate one authoritative repository and publisher identity, then make the author metadata and all installation instructions consistent.
- Pin installation to a reviewed immutable commit hash or versioned release rather than the repository's mutable default branch.
- Publish checksums or cryptographic signatures for release artifacts and require verification before installation.
- Configure the registry package to reference the same authoritative source and verified release.
- Document the expected repository owner, package identifier, release version, commit hash, and integrity value.
- Review updates before activation and avoid granting newly introduced permissions automatically.
- Treat a change in repository ownership, registry publisher, requested permissions, or integrity metadata as requiring a new security review.
