T08 · Insecure Dependencies
- Location
SKILL.md:166- Finding
Unpinned Third-Party Dependency Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 166-169
Vulnerability Type: Supply-chain risk from mutable, unpinned dependencies
Risk Level: MediumVulnerable Code
text **Claude Code, Cursor, Codex + 70 more agents:** `npx skills add cellcog/skills --skill cellcog` **OpenClaw:** `openclaw skills install @cellcog/cellcog` **CellCog plugin users:** run `/cellcog-setup` (or `/cellcog:cellcog-setup` depending on your tool) **Manual setup:** `pip install -U cellcog` and set `CELLCOG_API_KEY`. See the **cellcog** skill for SDK reference.Technical Analysis
The setup instructions install or upgrade third-party packages without specifying an immutable version, lockfile, or integrity hash. Consequently, the code executed by these commands can change after this Skill has been reviewed.
In particular,
pip install -U cellcogexplicitly upgrades to the latest package version available from the configured Python package index. Thenpxand OpenClaw installation commands similarly do not identify a reviewed version. Package installation may execute package lifecycle hooks, while subsequently importing the installed SDK executes its Python code. The actual dependency contents are not included in this project and therefore could not be audited.This is a supply-chain weakness rather than evidence that the current CellCog packages are malicious. Exploitation depends on compromise of a package publisher, registry account, distribution infrastructure, or transitive dependency.
Attack Path
- An attacker compromises a referenced package, its publisher account, its release process, or a transitive dependency.
- The attacker publishes a malicious release under the package identifier used by the documented command.
- A user follows the Skill's unpinned setup instructions.
- The package manager retrieves the latest mutable release rather than a previously reviewed version.
- Malicious code e ...[truncated 878 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin every dependency and Skill installation to a specific version that has been reviewed, rather than implicitly installing the latest release.
- Use cryptographic hashes or signed release verification where supported. For Python, provide a requirements file with exact versions and hashes and install it with hash enforcement.
- Supply and maintain lockfiles for all package ecosystems involved, including transitive dependencies.
- Remove
-Ufrom the default installation command so installation does not silently replace a reviewed version with an unreviewed release. - Document the expected package publisher, registry, package identifier, version, and release checksum so users can verify provenance.
- Review new releases before updating pinned versions, including installation hooks and transitive dependency changes.
- Perform installation in an isolated, least-privileged environment and avoid exposing unrelated secrets during installation or first import.
- Consider vendoring or otherwise distributing the exact reviewed integration code when reproducible package resolution cannot be guaranteed.
