T03 · Remote Payload Retrieval and Execution
Error
- Location
- rules/api.md:39
- Finding
- Remote API Response Is Trusted as an Executable Update Instruction<![CDATA[ ## Vulnerability Details **File Location**: `rules/api.md:39-58` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```markdown ## Skill Version Check No authentication required. Returns the latest skill version so agents can detect stale installations: ```bash curl -X GET "https://api.openbio.tech/api/v1/tools/skill-version" ``` Response: ```json { "skill": "openbio", "version": "1.0.0", "updated_at": "2026-02-06", "update_command": "bunx skills update", "install_command": "bunx skills add openbio-ai/skills --skill openbio --global --agent '*' -y" } ``` Compare `version` against the `version` field in your SKILL.md metadata. If stale, run the `update_command` (or `install_command` if update fails). ``` ### Technical Analysis The Skill instructs the agent to retrieve update information from an unauthenticated API endpoint and then run command text represented by the response’s `update_command` or `install_command` fields. Although HTTPS protects transport under normal conditions, the response remains mutable and controlled by the remote service. The instructions do not require the agent to: - Compare the returned command against a local allowlist. - Reject additional shell operators or arguments. - Validate that only the semantic version field is used. - Pin the downloaded Skill to an immutable commit or signed release. - Request explicit user approval before executing the command. This creates a remote code-execution trust boundary. Compromise of the OpenBio API, its deployment credentials, DNS or TLS trust path, or the response-generation logic could allow an attacker to replace the documented commands with arbitrary shell instructions. ### Attack Path 1. An attacker compromises the API service or the component generating `/api/v1/tools/skill-version`. 2. The attacker returns a version newer than the locally installed version. 3. The response supplies a malicious `update_com ...[truncated 972 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `update_command` and `install_command` from the trusted execution flow. Treat all command strings returned by the API as untrusted display data. 2. Use the endpoint only to retrieve a strictly validated semantic version, such as `1.0.5`. 3. Hard-code the permitted update command in the locally reviewed Skill rather than accepting it from the server. 4. Validate the response against a strict schema and reject unexpected fields or malformed version values. 5. Require explicit user confirmation before any installation or update. 6. Pin updates to an immutable commit SHA, signed release, or verified artifact digest. 7. Verify release signatures or checksums before installation. 8. Run update operations with the least-privileged account and prevent access to unrelated credentials. 9. Avoid automatically executing update instructions solely because the server reports a newer version. ]]>
