T03 · Remote Payload Retrieval and Execution
- Location
scripts/install_or_update.sh:5- Finding
Unpinned Remote Repository Is Retrieved and Installed as Executable Python Code
- Content
View full analysis
Vulnerability Details
File Location:
scripts/install_or_update.sh, lines 5–15
Vulnerability Type: Unverified remote payload retrieval and installation
Risk Level: HighVulnerable Code
bash REPO_URL="${REPO_URL:-https://github.com/NeverChenX/ClawStatus.git}" if [[ -d "$TARGET_DIR/.git" ]]; then echo "[clawstatus] updating existing checkout: $TARGET_DIR" git -C "$TARGET_DIR" pull --ff-only else echo "[clawstatus] cloning repo to: $TARGET_DIR" git clone "$REPO_URL" "$TARGET_DIR" fi echo "[clawstatus] installing editable package" python3 -m pip install --user --break-system-packages -e "$TARGET_DIR"Technical Analysis
The installation script clones or updates a mutable remote Git repository and immediately passes the resulting checkout to
pip. It does not pin an audited commit hash, verify a cryptographic checksum, validate a signed commit or tag, or confirm that an existing checkout still uses the intended remote repository.Python package installation can execute project-controlled build backend logic or setup code. Consequently, the effective code executed or installed by this Skill can change after the Skill itself has been reviewed. The risk applies both to new installations and updates:
- New installations retrieve the current state of the remote repository rather than an immutable revision.
- Existing installations trust the checkout's currently configured Git remote.
- The
REPO_URLenvironment variable allows the source repository to be replaced by the caller's environment. --break-system-packagesbypasses the distribution-managed Python environment safeguard and increases the chance of altering or conflicting with user-visible system Python packages.- Editable installation causes subsequent execution to continue using code from the mutable checkout.
No evidence establishes that the referenced upstream repository is currently malicious. The vulnerabil ...[truncated 1853 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the installation to a specific, reviewed full commit hash rather than the repository's moving default branch.
- Verify the checked-out commit against the expected hash before invoking Python or
pip. - Where available, require and verify a signed commit or signed release tag against an explicitly trusted maintainer key.
- Do not allow unrestricted
REPO_URLoverrides. If configurability is required, validate the URL against an explicit allowlist and require a corresponding trusted revision. - For an existing checkout, verify that
remote.origin.urlmatches the expected canonical repository before pulling. - Avoid automatically updating and installing in one operation. Retrieve the update, verify it, and only then perform installation as a separate step.
- Install into a dedicated virtual environment instead of using
--user --break-system-packages. - Lock and verify build and runtime dependencies, including build-system requirements declared by the downloaded project.
- Prefer an immutable, reproducibly built release artifact with a published checksum over an editable installation from a mutable checkout.
- If editable mode is necessary for development, clearly restrict it to trusted development environments and revalidate the checkout before every execution.