T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:20- Finding
Unpinned Remote Docker Deployment Allows Mutable Code Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 20–23
Vulnerability Type: Remote payload retrieval and execution through an unpinned Git repository and Docker deployment
Risk Level: Highbash git clone https://github.com/2dogsandanerd/ClawRag.git cd ClawRag cp .env.example .env docker compose up -dTechnical Analysis
The installation procedure clones the current state of a remote repository without specifying a reviewed commit hash or immutable release tag. It then immediately processes the repository's Docker Compose configuration and starts its containers.
The effective executable payload is not present in the audited skill package and can change after the skill has been reviewed. Docker Compose files may define arbitrary images, build instructions, entry points, host directory mounts, environment variables, network exposure, Linux capabilities, or privileged container settings. The skill provides no image-digest verification, repository integrity check, or mandatory review step before execution.
Attack Path
- An attacker compromises the upstream GitHub repository, a maintainer account, or an indirectly referenced container image.
- The attacker modifies the default branch, Compose configuration, Docker build context, or mutable image tag.
- A user follows the documented
git cloneinstructions and receives the attacker-controlled version. - The user runs
docker compose up -d. - Docker builds or retrieves the modified components and executes them.
- Depending on the Compose permissions and mounts, the payload may access configured API keys, application data, host-mounted files, exposed services, and Docker-accessible resources.
Impact Assessment
Successful exploitation can result in arbitrary containerized code execution. The practical scope depends on the Docker daemon configuration and the remote Compose file. If sensitive host paths, the Docker socket, elevated capabilities, host networking, or privi ...[truncated 238 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the repository to a reviewed commit hash rather than implicitly using the default branch.
- Reference container images by immutable digest, such as
image@sha256:..., instead of mutable tags. - Publish expected commit identifiers and image digests in the installation instructions.
- Require users to inspect the Compose file, Dockerfiles, entry points, mounts, capabilities, ports, and environment-variable handling before startup.
- Avoid privileged containers, host PID or network modes, sensitive host mounts, and Docker socket exposure.
- Run containers as non-root users with read-only filesystems, dropped Linux capabilities, resource limits, and narrowly scoped networks where possible.
- Add signature or checksum verification for downloaded artifacts and container images.
- Recommend deploying the service in an isolated virtual machine or restricted Docker environment when processing sensitive documents.