T08 · Insecure Dependencies
Warning
- Location
- auth-and-clis.md:29
- Finding
- Mutable and Unverified CLI Dependencies Can Execute Unreviewed Code<![CDATA[ ## Vulnerability Details **File Location**: `auth-and-clis.md:29-34` and `auth-and-clis.md:61-64` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: Medium ### Vulnerable Code `auth-and-clis.md:29-34`: ```bash Alternative binary install: ```bash curl -LO "https://acli.atlassian.com/darwin/latest/acli_darwin_arm64/acli" chmod +x ./acli ./acli --help ``` ``` `auth-and-clis.md:61-64`: ```bash Install and login: ```bash npm i -g @forge/cli@latest forge login ``` ``` ### Technical Analysis Both installation methods rely on mutable `latest` references. The ACLI instructions download a binary, grant it execute permission, and run it without validating a cryptographic checksum or digital signature. The Forge instructions install the mutable `@latest` package globally without pinning a reviewed version. Consequently, the code installed at audit time is not guaranteed to be the code installed when a user follows these instructions. Although both dependencies are obtained from apparently official distribution channels, compromise of an upstream release, package-publishing account, registry, download endpoint, or associated trust infrastructure could substitute attacker-controlled executable content. The global npm installation also places the Forge executable in a system-wide user tool location, increasing the likelihood that a compromised version will continue to be invoked in later sessions. ### Attack Path 1. An attacker compromises the ACLI distribution endpoint, Forge npm publishing account, upstream build process, or a release referenced by `latest`. 2. The mutable URL or npm tag is changed to resolve to an attacker-controlled artifact. 3. A user follows the Skill instructions. 4. For ACLI, the user downloads the artifact, marks it executable, and runs it without integrity verification. 5. For Forge, npm installs the compromised package globally and may execute package lifecycle scripts during installation. 6. The malicious depen ...[truncated 925 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace `/latest/` and `@latest` with exact, reviewed version numbers. 2. Publish the expected SHA-256 checksum for every downloaded binary. 3. Verify the checksum before granting execute permission or running the binary. 4. Where Atlassian provides signed releases, verify the release signature against a documented and trusted signing key. 5. Use installation commands that fail closed if verification fails. 6. Avoid global npm installation where practical. Prefer a project-local, version-pinned dependency with a lockfile. 7. Review npm lifecycle scripts before installation and consider disabling them during initial package retrieval where operationally feasible. 8. Document an explicit upgrade process so new versions are reviewed and their hashes updated rather than silently selected through a mutable tag. A hardened binary workflow should follow this pattern: ```bash ACLI_VERSION="<reviewed-version>" curl -fL -o acli "https://<official-versioned-path>/${ACLI_VERSION}/acli" printf '%s %s\n' "<published-sha256>" "acli" | shasum -a 256 --check - chmod 700 ./acli ./acli --version ``` The exact versioned URL, checksum, and signature procedure must come from verified Atlassian release documentation. ]]>