T03 · Remote Payload Retrieval and Execution
Error
- Location
- references/install.md:11
- Finding
- Mutable Remote Installer Is Downloaded and Executed Without Independent Authentication## Vulnerability Details **File Location**: `references/install.md`, lines 11-19 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```markdown - Unix installer: `https://github.com/FlanChanXwO/pixiv-cli/releases/latest/download/install.sh` - Windows CMD installer: `https://raw.githubusercontent.com/FlanChanXwO/pixiv-cli/main/scripts/install.cmd` Download and inspect the selected script before execution. Do not substitute a mirror, custom base URL, package copied from chat, or an improvised installer. The installer itself must select the latest stable official Release and report `SHA-256 verified` before replacing a binary. ``` ### Technical Analysis The installation workflow retrieves executable installer code from mutable remote locations. The Unix URL follows the `latest` release, while the Windows installer is retrieved from the moving `main` branch. Consequently, the code ultimately executed can change after this Skill has been reviewed. The requirement to inspect the script provides a procedural safeguard, but it does not cryptographically authenticate the installer or ensure that an automated inspection will identify a sophisticated malicious modification. Similarly, a binary checksum validated by the remotely downloaded installer is not an independent trust boundary: a compromised installer can replace both the expected checksum and the binary, falsely print `SHA-256 verified`, or execute unrelated commands before verification. Installation is necessary only when explicitly requested, and the Skill correctly limits installation to a per-user destination without administrator privileges. These controls reduce exposure and privilege, but they do not eliminate the remote-code-execution risk at the current user's privilege level. ### Attack Path 1. An attacker compromises the repository, maintainer account, release publishing credentials, or delivery pat ...[truncated 1407 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `latest` and `main` URLs with immutable, reviewed release versions and commit-addressed resources. 2. Publish an expected installer SHA-256 digest in a separately controlled, immutable location and verify it before invoking the script. 3. Prefer cryptographic release signatures using a pinned maintainer public key. Verify both the installer and downloaded binary against signed release metadata. 4. Do not rely on a checksum embedded in, downloaded by, or interpreted solely by the installer being authenticated. 5. Download the installer to a private temporary file, reject symlinks and unsafe permissions, verify its digest or signature, and execute the exact verified file. 6. Preserve the existing explicit-installation consent requirement, per-user destination, pre-execution disclosure, and prohibition on administrator or root privileges. 7. Pin the expected binary version and independently verify the installed binary after installation rather than trusting installer-generated text such as `SHA-256 verified`. 8. For Windows, reference an immutable commit or signed release asset instead of the moving `main` branch.
