T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:82- Finding
Unpinned Remote Repository Retrieved and Executed Through Docker Compose
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 82–84
Vulnerability Type: Remote payload retrieval and execution
Risk Level: HighVulnerable Code
bash git clone https://github.com/celstnblacc/youtube-model-feeder.git cd youtube-model-feeder docker-compose up -dTechnical Analysis
The installation procedure clones the mutable default branch of an external Git repository and immediately launches its Docker Compose stack. It does not pin a reviewed commit or release, verify a checksum or cryptographic signature, or pin container images by immutable digest.
Consequently, the effective code executed by users can change after this skill has been reviewed. The audited package contains only
SKILL.md; the referenced source code, Compose configuration, Dockerfiles, container entry points, volume mounts, privileges, and image definitions are not included and therefore could not be verified during this audit.This behavior most closely matches
T03: Remote Payload Retrieval and Execution: an external source controls a payload that is retrieved and subsequently executed. Although it also creates supply-chain risk, the direct clone-and-run sequence makes remote payload execution the best matching classification.Attack Path
- An attacker compromises the upstream repository, a maintainer account, a build pipeline, or an unpinned container image referenced by the Compose configuration.
- The attacker modifies the default branch or container image to include malicious startup commands.
- A user follows the documented installation procedure and clones the current, attacker-controlled repository content.
- The user runs
docker-compose up -d, causing Docker to build, retrieve, and start the altered services. - The malicious service executes with the permissions and resources granted by Docker Compose, including any configured networks, environment variables, bind mounts, named volumes, ...[truncated 1104 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the repository to a specific, reviewed commit hash rather than relying on the mutable default branch:
bash git clone https://github.com/celstnblacc/youtube-model-feeder.git cd youtube-model-feeder git checkout --detach VERIFIED_COMMIT_HASH - Publish the expected commit hash through a trusted release channel and require users to verify it before execution.
- Sign releases or commits and document signature verification using a trusted maintainer key.
- Pin every container image in the Compose file by immutable SHA-256 digest rather than by mutable tags such as
latest. - Provide checksums or attestations for source archives, images, and generated artifacts. Verify them before starting services.
- Include the exact reviewed
docker-compose.yml, Dockerfiles, and startup scripts in the skill package so their permissions, mounts, ports, and commands can be audited. - Apply least privilege to every service: avoid privileged containers, host networking, Docker socket mounts, unnecessary capabilities, host-device access, and writable host bind mounts.
- Do not pass unrelated host secrets into containers. Use narrowly scoped credentials and explicit secret management.
- Add a review step between retrieval and execution rather than immediately running the downloaded stack.
- Document all external network access, exposed ports, filesystem mounts, requested privileges, and data sent to third-party providers.
- Pin the repository to a specific, reviewed commit hash rather than relying on the mutable default branch:
