T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:55- Finding
Unpinned Remote Code Is Retrieved, Installed, and Automatically Executed
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 17-22 and 55-62
Vulnerability Type: Remote payload retrieval and execution
Risk Level: HighVulnerable code snippet:
text Agent workflow: 1. Check if AutoResearchClaw is installed (`which researchclaw`) 2. If not installed: clone, setup venv, install with `pip install -e .` 3. Copy `config.researchclaw.example.yaml` → `config.arc.yaml` 4. Ask user for LLM provider choice (OpenAI-compatible or ACP agent) 5. Configure with API keys or ACP agent selection 6. Run: `researchclaw run --topic "[topic]" --auto-approve`bash cd ~ git clone https://github.com/aiming-lab/AutoResearchClaw.git cd AutoResearchClaw python3 -m venv .venv source .venv/bin/activate pip install -e .Technical Analysis
The Skill instructs the agent to clone the mutable default branch of an external Git repository, install it as a Python package, and execute its research pipeline. It does not pin the repository to a reviewed commit or signed release, verify artifact integrity, or lock transitive dependencies with cryptographic hashes.
pip install -e .processes package metadata and build configuration supplied by the retrieved repository. Depending on the package and build backend, installation can execute attacker-controlled build or installation logic. The installedresearchclawcommand then executes code from the same externally controlled source.The subsequent use of
--auto-approvefurther reduces oversight over the pipeline's actions and generated experimental code. The effective executable payload can therefore change after the Skill itself has been reviewed. This behavior exceeds the minimum privileges required to provide research guidance because it grants an unreviewed remote project local code-execution capability.Attack Path
- An attacker compromises the upstream repository, a maintainer account, the repository's release pr ...[truncated 1731 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the external repository to a specific, independently reviewed commit hash rather than cloning and executing its mutable default branch.
- Verify the repository or release using a trusted signature, checksum, or provenance attestation before installation.
- Use a dependency lockfile that pins all direct and transitive dependencies. Require cryptographic hashes for downloaded Python packages.
- Prefer a pre-reviewed, reproducible artifact from a trusted registry over an editable installation from a live Git checkout.
- Run installation and pipeline execution inside an ephemeral sandbox or container with:
- A read-only or narrowly scoped filesystem.
- No access to unrelated home-directory files.
- A minimal environment containing only the credentials required for the selected provider.
- Network egress restricted to explicitly approved LLM and literature-search endpoints.
- CPU, memory, runtime, process, and GPU limits.
- Remove
--auto-approvefrom the default workflow. Require explicit user approval before generated code is executed, dependencies are added, external messages are sent, or files outside the dedicated artifact directory are modified. - Keep API credentials outside project configuration files, pass them through a scoped secret mechanism, and prevent child processes from inheriting credentials they do not require.
- Review generated experimental code before execution and run it in a separate sandbox without access to LLM credentials or unrelated user data.
- Disable optional scheduling, persistent memory, messaging, browser access, and parallel-session features by default. Enable each capability only after obtaining explicit user consent and applying destination and permission allowlists.