T03 · Remote Payload Retrieval and Execution
Warning
- Location
- SKILL.md:14
- Finding
- Unpinned Remote Executable Download Without Integrity Verification## Vulnerability Details **File Location**: `SKILL.md`, lines 14–26 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Medium ```bash # From a directory on your PATH or the skill directory LATEST_URL=$(curl -sL -o /dev/null -w '%{url_effective}' https://github.com/craftslab/gomail/releases/latest) VERSION=${LATEST_URL##*/} # e.g. v2.7.2 VERSION_NO_V=${VERSION#v} # e.g. 2.7.2 # Note: the release tag includes a leading "v", but the tarball filename does not. wget "https://github.com/craftslab/gomail/releases/download/${VERSION}/gomail_${VERSION_NO_V}_linux_amd64.tar.gz" tar -xf "gomail_${VERSION_NO_V}_linux_amd64.tar.gz" # Ensure the binaries are executable chmod +x sender parser ``` ### Technical Analysis The installation procedure dynamically resolves the latest release and downloads a precompiled archive from an external GitHub repository. It neither pins a previously reviewed version nor verifies the archive using a cryptographic digest or trusted signature before extracting it and making its binaries executable. Consequently, the effective executable payload may change after the Skill itself has been reviewed. A compromise of the upstream repository, maintainer account, release workflow, or hosted artifact could cause users to retrieve and execute attacker-controlled code. TLS protects the download in transit but does not establish that the release artifact is the specific artifact reviewed or approved by the Skill publisher. Downloading a binary is functionally necessary because the Skill delegates email delivery to the `sender` CLI. However, dynamically selecting an unverified latest release exceeds the minimum risk necessary to provide that functionality. In addition, `chmod +x sender parser` grants execution permission to `parser`, although the declared workflow only requires `sender`. The downloaded archive was not included in the audited project, so its internal beha ...[truncated 1479 chars]
- Remediation
- ## Remediation Suggestions 1. Pin an explicitly reviewed release version rather than resolving `/releases/latest` during installation. 2. Publish an expected SHA-256 or stronger digest in the Skill and verify the downloaded archive before extraction. Abort installation on any mismatch. 3. Where available, verify a signed release or provenance attestation against a documented, trusted maintainer key or identity. 4. Prefer building the executable from a pinned source revision in a controlled and reproducible build environment. 5. Download and extract into a dedicated, non-privileged directory. Avoid running installation steps as root unless installation to a protected path is strictly required. 6. Inspect the archive contents before extraction and use defensive extraction controls to prevent unexpected paths or files from being written. 7. Install and grant execution permission only to the required `sender` binary. Do not mark `parser` executable unless a documented workflow genuinely requires it. 8. Document the exact reviewed source revision, release version, artifact name, checksum, architecture, and verification procedure. 9. Run the email client with least privilege and limit its filesystem access to the required configuration, message body, and explicitly selected attachments.