T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:45- Finding
Unverified Third-Party Code Retrieval and Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 45 and 54–60
Vulnerability Type: Remote code retrieval through unverified package and source installation
Risk Level: MediumVulnerable Code:
bash pip install ilc-core==0.4.19 ilc version # should report 0.4.19bash git clone https://github.com/jamison/ilc.git cd ilc python3 --version # must be Python 3.10+ python3 -m venv .venv source .venv/bin/activate python -m pip install --upgrade pip python -m pip install -e ".[openclaw-hosted]"Technical Analysis
The skill directs users to retrieve and install executable code from PyPI and a remote Git repository, but none of that executable code is included in the audited artifact. Consequently, the behavior of package installation hooks, build-system configuration, optional dependencies, and transitive dependencies cannot be verified from this project.
The PyPI package is version-pinned, which reduces accidental version drift, but no package hashes or signatures are verified. The source installation is more exposed because
git cloneretrieves the repository's mutable default branch rather than a reviewed immutable commit or cryptographically verified signed tag. The subsequent editable installation can execute attacker-controlled build hooks and resolve additional dependencies.This finding does not establish that the referenced package or repository is malicious. It identifies an unsafe trust boundary through which upstream compromise or later repository modification could introduce executable payloads after this skill has been reviewed.
Attack Path
- An attacker compromises the referenced PyPI release, repository, maintainer account, build pipeline, or a resolved transitive dependency.
- The attacker adds malicious package initialization, build-backend logic, installation hooks, or dependency content.
- A user follows the installation commands in
SKILL.md...[truncated 929 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin source installations to a reviewed full commit hash or a cryptographically verified signed release tag rather than the mutable default branch.
- Publish a locked dependency manifest containing cryptographic hashes for all direct and transitive packages.
- Use pip's hash-checking mode, such as
--require-hashes, with an audited requirements file. - Provide package provenance, signatures, or attestations and document the exact verification procedure users must perform before installation.
- Vendor the executable implementation into the reviewed artifact when practical, allowing its installation and runtime behavior to be audited together with the skill.
- Avoid the unnecessary
pipself-upgrade during installation, or pin and verify the intended pip distribution. - Recommend installation in an isolated, non-privileged virtual environment without sensitive environment variables or credentials.
- Audit build-system hooks, optional
openclaw-hosteddependencies, and all transitive dependencies before publishing approved hashes.
