T03 · Remote Payload Retrieval and Execution
- Location
references/atlas-guide.md:9- Finding
Unpinned Third-Party Package and Mutable Remote Repository Are Executed Without Integrity Verification
- Content
View full analysis
Vulnerability Details
File Location:
references/atlas-guide.md:9-43; related instructions also appear inSKILL.md:17,73andscripts/verify_deploy.py:69,108
Vulnerability Type: Unverified third-party supply-chain execution and remote payload retrieval
Risk Level: MediumVulnerable Code Snippets
references/atlas-guide.md:9bash - bonito-cli: `pip install bonito-cli`references/atlas-guide.md:14-25bash git clone https://github.com/ShabariRepo/atlas.git cd atlas cp .env.example .env # Edit .env with your Bonito credentials + at least one provider key # (or use managed inference — just set BONITO_EMAIL/PASSWORD/API_URL) # Start 4 mock MCP servers (GitHub, PagerDuty, Slack, Jira on ports 3100-3103) docker compose -f docker-compose.mcp.yml up -d # Authenticate and deploy bonito auth login bonito deploy -f bonito.yaml # --dry-run to validate firstreferences/atlas-guide.md:43bash ./scripts/test-agents.shRelated package installation instructions in
SKILL.md:17,73:bash pip install bonito-cliRelated recommendations in
scripts/verify_deploy.py:69,108:python check("bonito-cli", False, "not found — run: pip install bonito-cli")python print(" Clone with: git clone https://github.com/ShabariRepo/atlas.git")Technical Analysis
The onboarding instructions install
bonito-cliwithout pinning an exact reviewed version or verifying a package hash or signature. The Atlas demonstration is similarly cloned from a mutable Git repository reference rather than a verified commit.The workflow subsequently executes repository-controlled content through:
docker compose, which processes the remotely retrieved Compose configuration and may build or run images with host mounts, environment variables, and network access.bonito deploy, which processes the remotely retrievedbonito.yamland ...[truncated 2680 chars]
- Remediation
View remediation
Remediation Suggestions
-
Pin
bonito-clito an exact reviewed version rather than installing the latest available release:bash python3 -m pip install "bonito-cli==REVIEWED_VERSION" -
Publish and verify cryptographic hashes for the package and all locked dependencies. Use a requirements file with hashes, for example:
bash python3 -m pip install --require-hashes -r requirements.lock -
Clone Atlas and explicitly check out a reviewed immutable commit:
bash git clone https://github.com/ShabariRepo/atlas.git cd atlas git checkout --detach REVIEWED_COMMIT_SHA -
Document the expected commit identifier and, where available, verify a signed commit or signed release tag before executing repository content.
-
Require inspection of
docker-compose.mcp.yml,bonito.yaml, Dockerfiles, referenced images, andscripts/test-agents.shbefore execution. Container images should be pinned by immutable digest rather than mutable tags. -
Make
bonito deploy --dry-run -f bonito.yamla mandatory validation step, require review of the generated plan, and request explicit confirmation before performing the real deployment. -
Run the demonstration in an isolated virtual environment or disposable virtual machine. Avoid installing the CLI globally or as a privileged account.
-
Use dedicated, short-lived, least-privilege Bonito and provider credentials. Do not reuse production credentials, and revoke or rotate demonstration credentials after use.
-
Restrict Docker permissions and avoid exposing the host Docker socket or sensitive host paths to demonstration containers.
-
Add clear warnings that the Atlas repository is external, its contents are not part of the audited skill package, and users must verify the pinned revision before execution.
-
