T03 · Remote Payload Retrieval and Execution
Error
- Location
- install.sh:25
- Finding
- Mutable External Repository Is Downloaded, Installed, and Executed<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:25-32, 40-56, 62-80`; `SKILL.md:42-59` **Vulnerability Type**: Mutable remote payload execution and unsafe dependency installation **Risk Level**: High ### Vulnerable Code ```bash # Download complete system code if [ ! -d "autocraft-opensource" ]; then echo "Downloading from GitHub..." git clone https://github.com/Robin-Chen2025/autocraft-opensource.git || { echo "GitHub download failed, trying Gitee..." git clone https://gitee.com/Robin-Chen2025/autocraft-opensource.git } else echo "autocraft-opensource directory already exists, skipping download" fi cd autocraft-opensource # Install backend dependencies cd backend if [ ! -d "venv" ]; then python3 -m venv venv fi source venv/bin/activate pip install -r requirements.txt # Install frontend dependencies npm install # Start backend cd backend source venv/bin/activate nohup python3 -m uvicorn main:app --host 0.0.0.0 --port 9001 > /tmp/autocraft_backend.log 2>&1 & # Start frontend nohup npm run dev > /tmp/autocraft_frontend.log 2>&1 & ``` ### Technical Analysis The installer clones the current default branch of a separately maintained external repository without pinning an immutable commit, verifying a cryptographic checksum, or validating a release signature. It subsequently installs dependencies specified by that downloaded repository and executes its backend and frontend. This creates a time-of-check/time-of-use supply-chain boundary: the effective code executed during installation can differ from the code reviewed in this Skill package. Python package build hooks and npm lifecycle scripts may execute code during installation, while the downloaded backend and frontend are explicitly launched afterward. The GitHub-to-Gitee fallback increases the number of remote trust sources. A compromise of either repository, its maintainer account, a referenced dependency, or a package registry can alter the executed p ...[truncated 1226 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Package the reviewed application code directly with the Skill, or pin the clone to a specific immutable commit hash. 2. Verify downloaded source against a cryptographically signed release and a hardcoded SHA-256 or stronger digest before installation. 3. Fail closed if verification fails; do not silently switch to a second mutable source. 4. Use hash-locked Python dependencies, such as a requirements file containing exact versions and `--hash` entries. 5. Commit and audit an npm lockfile, then use `npm ci` rather than `npm install`. 6. Disable npm lifecycle scripts during installation where feasible, for example with `npm ci --ignore-scripts`, and explicitly run only reviewed build steps afterward. 7. Perform dependency installation and application execution in a dedicated, unprivileged account or container with restricted filesystem and network access. 8. Clearly display the exact repository commit and dependency lockfile versions before obtaining user approval. ]]>
