T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:44- Finding
Mutable Remote Documentation Is Used as an Executable Code Source
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 44–60 and 84–87
Vulnerability Type: Remote payload retrieval and execution
Risk Level: HighVulnerable Code Snippet
markdown ## Authoritative tool-doc source (required) The published Markdown files under `https://sciminer.tech/tool_api_files/` are the single source of truth for `provider_name`, `tool_name`, allowed `parameters`, file-upload behavior, request encoding, and the example submission flow for this skill's included tools. Use these SciMiner Markdown docs: - `Transformer-Based Proprietary Library Virtual Screen` -> `Transformer-Based Proprietary Library Virtual Screen_api_doc.md` - `Docking-Based Proprietary Library Virtual Screen` -> `Docking-Based Proprietary Library Virtual Screen_api_doc.md` - `Transformer-Based Open Library Virtual Screen` -> `Transformer-Based Open Library Virtual Screen_api_doc.md` - `Docking-Based Open Library Virtual Screen` -> `Docking-Based Open Library Virtual Screen_api_doc.md` The agent MUST: 1. Resolve the selected tool's Markdown file and read it before every invocation. 2. Never invent `provider_name`, `tool_name`, parameter names, enum values, upload-field names, content type, or submission flow from memory. 3. Extract and follow the selected doc section's exact:markdown 5. Upload required file inputs exactly as described by the selected Markdown doc and replace local paths with returned `file_id` values. 6. Write or run the invocation code directly from the selected Markdown doc's base-information block, parameter table, file-upload instructions, and example code. Do not apply a shared invocation template or local registry abstraction in this skill.Technical Analysis
The Skill requires the agent to retrieve mutable Markdown documents from an external website before every invocation and then “write or run” invocation code based directly ...[truncated 3197 chars]
- Remediation
View remediation
Remediation Suggestions
- Bundle reviewed invocation logic locally. Store the API client and fixed request-building logic inside the Skill package instead of generating or executing code from remote examples.
- Pin external specifications. If remote documentation must be consulted, pin an immutable version and verify it against a cryptographic digest included in the reviewed package.
- Never execute documentation examples. Parse remote documentation only as untrusted reference text. Do not evaluate, import, source, or copy its executable examples into an interpreter.
- Enforce a local allowlist. Define permitted HTTPS origins, endpoints, HTTP methods, authentication-header placement, upload fields, content types, parameter names, and response fields in reviewed local code.
- Separate credentials from generated code. Use a constrained HTTP client or credential broker that can attach
X-Auth-Tokenonly to an explicitly allowlisted SciMiner origin. Invocation code should never receive the raw token. - Restrict redirects and destinations. Reject cross-origin redirects and prevent credentials or uploaded files from being sent to hosts outside the approved SciMiner domain.
- Sandbox execution. If code generation remains unavoidable, run it without shell access, with a read-only filesystem, restricted outbound networking, no direct credential-file access, and access only to explicitly approved input files.
- Require explicit upload approval. Before uploading user files, display the destination, file names, and data categories and obtain user confirmation.
- Validate remote content as data. Apply a strict schema to any remotely sourced parameter metadata and reject executable blocks, unexpected endpoints, unknown fields, and instructions unrelated to the documented API operation.
- Add integrity monitoring. Monitor the hosted documentation and deployment pipeline for unauthorized changes, and conduc ...[truncated 67 chars]
