Gleam performs dependency resolution by first pulling signed metadata from the Hex repository and then querying an unsigned Hex API for release information. The unsigned API response is used to populate the manifest file, including the checksum that verifies the package archive. Because the API response is not signed, an attacker who can intercept TLS—such as through a proxy bearing a trusted CA certificate—can alter both the API JSON and the corresponding tarball, presenting a forged checksum that matches the malicious archive. Gleam then verifies the tarball against this forged checksum, accepts it, and extracts the malicious content, thereby compromising the integrity of the downloaded package. This weakness is a classic example of a Three‑Party Problem (CWE‑345).

The vulnerability affects the Gleam programming language distribution. Any installation of Gleam between version 0.18.0 and before 1.18.0 is susceptible. The impact applies to builds that trigger dependency resolution or updates, such as during a fresh project creation, adding or updating a hex dependency, or when dependency requirements change. Builds that reuse a previously pinned manifest.toml are not affected because the checksum check falls back to the stored value.

The CVSS score of 7.6 classifies the issue as a high‑severity integrity problem, but the EPSS score is below 1%, indicating a low likelihood of exploitation at time of analysis. The vulnerability requires a man‑in‑the‑middle capable of presenting a trusted TLS certificate to the Gleam process (for example, a corporate proxy with a certificate in the system trust store or set via GLEAM_CACERTS_PATH). Because the vulnerability is not listed in the CISA KEV catalog, no widespread active exploitation has been reported yet. The risk remains significant for environments that rely on third‑party proxies or that do not strictly control accepted TLS certificates, and mitigation should focus on removing the opportunity for MITM interception or updating to the fixed version.