T03 · Remote Payload Retrieval and Execution
Warning
- Location
- README.md:7
- Finding
- Unpinned Third-Party Source Is Downloaded, Compiled, and Executed## Vulnerability Details **File Location**: `README.md`, lines 7-12 **Vulnerability Type**: Remote payload retrieval through an unpinned third-party dependency **Risk Level**: Medium ### Vulnerable Code ```bash # Install the llama.cpp TurboQuant fork git clone https://github.com/TheTom/llama-cpp-turboquant.git cd llama-cpp-turboquant cmake -B build -DGGML_METAL=ON && cmake --build build --config Release # Run with turbo4 (best quality/compression balance) ./build/bin/llama-server -m model.gguf --cache-type-k turbo4 --cache-type-v turbo4 -fa 1 ``` ### Technical Analysis The setup instructions clone the current default branch of an externally controlled GitHub repository without pinning a reviewed commit, verifying a signed release, or checking a cryptographic digest. They then instruct the user to compile and execute the retrieved source. Consequently, the effective executable payload can change after this skill package has been reviewed. Compromise of the repository, its maintainer account, or its upstream development process could cause future users to compile attacker-controlled code. The package's assertion that it has no dependencies is also incomplete because its advertised functionality relies on this external fork. The primary classification is remote payload retrieval and execution because mutable external code is explicitly fetched and run. It also creates a third-party supply-chain risk. ### Attack Path 1. An attacker compromises the referenced repository, its maintainer account, or another component of its source-control workflow. 2. The attacker inserts malicious source code into the repository's default branch. 3. A user follows the documented Quick Start procedure and runs the unpinned `git clone`. 4. The user compiles the downloaded source with CMake. 5. The user starts the resulting `llama-server` binary. 6. The malicious payload executes with the operating-system privileges of that user. ### Impact Assessment Successful exploitation ...[truncated 692 chars]
- Remediation
- ## Remediation Suggestions 1. Pin the repository to a specific, reviewed full commit hash rather than relying on its mutable default branch. 2. Prefer a signed release from a verified publisher and document how users must validate the signature. 3. Publish an expected SHA-256 or stronger digest for downloaded source archives or binaries and require verification before building or running them. 4. Record the external fork as an explicit dependency instead of declaring that the project has no dependencies. 5. Maintain a documented review process for every dependency revision and update the pinned reference only after security review. 6. Recommend building and initially testing the component in an isolated, least-privileged environment without sensitive credentials or writable access to important files. 7. If reproducible builds are available, publish build provenance and instructions for comparing locally generated artifacts against trusted outputs.