T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:94
- Finding
- Unverified Remote Skill Package Retrieval and Automatic Installation## Vulnerability Details **File Location**: `SKILL.md:94-99`; supporting flow in `references/alipay-paid-access.md:59-65` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical **Vulnerable code in `SKILL.md:94-99`:** ```markdown When fulfillment returns a paid Skill package: 1. Present the package name, version, and install instruction. 2. If the environment can install Skills directly, install it. 3. If not, provide the exact package URL or slug returned by the MCP. 4. Then tell the user to invoke the installed paid Skill to start. ``` **Supporting code in `references/alipay-paid-access.md:59-65`:** ```markdown 1. Call the merchant payment MCP/tool to create the order. 2. If a cashier URL is returned, pass the complete URL to the Alipay payment skill/MCP. 3. Wait for payment completion. 4. Query merchant order status or receive successful payment result. 5. Call `paid_skill_fulfill` or the operator fulfillment endpoint. 6. Return the real Skill package install URL/slug. 7. Only then start or install the full scenario. ``` ### Technical Analysis The launcher directs the Agent to retrieve a Skill package from an external fulfillment MCP or operator-controlled endpoint and install it automatically when direct installation is supported. The remotely returned package is not part of the audited project and can therefore change after this launcher has been reviewed. The workflow does not require any of the following controls before installation: - An allowlisted registry or download origin - Cryptographic verification of the publisher - A signed package manifest - A pinned package digest - Validation that the returned package ID and version correspond to the purchased SKU - Inspection of the package's instructions, scripts, permissions, or tool access - Explicit user approval after displaying the package origin and requested privileges A signed or short-lived d ...[truncated 2058 chars]
- Remediation
- ## Remediation Suggestions 1. Restrict package retrieval to a fixed HTTPS registry and an explicit allowlist of trusted origins. Reject redirects to unapproved domains. 2. Require every package to include a cryptographically signed manifest. Verify the signature against a locally pinned publisher key before installation. 3. Bind fulfillment metadata to the transaction, including the SKU, package ID, version, publisher, digest, and expected permissions. 4. Pin an approved SHA-256 digest for each package version and verify the complete downloaded artifact before extraction or installation. 5. Reject fulfillment responses whose package identity, version, digest, or publisher does not match the merchant-side SKU mapping. 6. Inspect package contents before activation. Block executable scripts, undeclared tools, excessive permissions, path traversal entries, symbolic-link escapes, and unexpected nested downloads. 7. Display the verified publisher, source domain, version, digest, and requested permissions to the user, then require explicit confirmation before installation. 8. Install downloaded packages in a sandbox with least-privilege tool access. Do not inherit payment credentials, merchant API tokens, or unrelated session secrets. 9. Separate payment confirmation from package trust decisions. A valid payment must never imply that a returned package is safe. 10. Maintain an append-only audit log of fulfillment responses, package digests, signature results, installation decisions, and activated versions. 11. Remove the automatic-installation instruction until all authenticity and integrity checks are implemented. Default to rejecting unverifiable packages rather than providing or invoking them.