T03 · Remote Payload Retrieval and Execution
- Location
install.sh:14- Finding
Unpinned Remote Code Retrieval and Dependency Installation
- Content
View full analysis
Vulnerability Details
File Location:
install.sh, lines 14 and 20-33
Vulnerability Type: Mutable remote payload retrieval and insecure dependency installation
Risk Level: HighVulnerable Code
bash REPO_URL="https://github.com/gonelake/multi-agent.git" # ── 1. Ensure project code is available ──────────────────── if [[ -d "${INSTALL_DIR}/.git" ]]; then echo "→ Updating project code..." git -C "${INSTALL_DIR}" pull --quiet echo "✓ Code updated: ${INSTALL_DIR}" else echo "→ Cloning project code..." git clone --quiet "${REPO_URL}" "${INSTALL_DIR}" echo "✓ Project downloaded: ${INSTALL_DIR}" fi # ── 2. Install Python dependencies ───────────────────────── if [[ -f "${INSTALL_DIR}/requirements.txt" ]]; then echo "→ Installing Python dependencies..." pip install --quiet -r "${INSTALL_DIR}/requirements.txt" echo "✓ Python dependencies installed" fiTechnical Analysis
The installer clones or updates the mutable default branch of an external Git repository without pinning a reviewed commit, verifying a signed release, or checking a cryptographic digest. Consequently, the code installed at a later date can differ from the code that was present when this Skill package was audited.
The installer then trusts the remotely retrieved
requirements.txtand invokespip installin the active Python environment. Python dependency installation can execute package build hooks and other installation-time code. No dedicated virtual environment, hash-locked dependency file, or package integrity verification is enforced.This behavior exceeds the minimum privileges necessary for registering the Skill documentation. Although downloading the associated writing application is part of the declared installation design, automatically retrieving mutable code and installing its dependencies without integrity controls is unnecessary. The executable Python application is absent from the audited artifact, so its network b ...[truncated 2029 chars]
- Remediation
View remediation
Remediation Suggestions
-
Pin the application source to an immutable revision
- Clone a specific reviewed commit rather than the mutable default branch.
- Verify that the checked-out commit exactly matches the expected commit identifier.
- Prefer a signed release and validate its signature.
-
Add cryptographic integrity verification
- Download a versioned release artifact with a published SHA-256 digest.
- Abort installation if signature or digest verification fails.
- Store the expected digest in the reviewed Skill package.
-
Eliminate automatic mutable updates
- Remove the unconditional
git pullbehavior. - Implement an explicit update command that identifies the old and new revisions and requires user approval.
- Require each new revision to undergo review before execution.
- Remove the unconditional
-
Lock and verify Python dependencies
- Pin all direct and transitive dependencies to exact versions.
- Use a hash-locked requirements file and install with
pip install --require-hashes. - Review packages for dependency confusion, typosquatting, and unexpected build dependencies.
-
Isolate the Python environment
- Create a dedicated virtual environment under the application directory.
- Invoke that environment's Python and
pipexplicitly. - Avoid modifying the user's global or unrelated project environment.
-
Vendor the audited implementation when practical
- Include the executable application source and locked dependency metadata in the reviewed artifact.
- If remote retrieval remains necessary, clearly display the exact source revision and obtain confirmation before downloading or executing it.
-
Protect sensitive configuration
- Restrict
.envpermissions to the owning user. - Ensure API keys are sent only to the explicitly configured provider.
- Document what article prompts, search results, and other content are transmitted to remote LLM services.
- Restrict
-