CVE-2026-59247 in gleam
Summary
by MITRE • 07/29/2026
Insufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package contents during dependency resolution.
During dependency resolution Gleam fetches package metadata from the signature-verified Hex repository, which covers each release's dependency requirements and SHA-256 outer_checksum. After resolving versions, gleam_cli::dependencies::lookup_package makes a second request to the unsigned Hex API through gleam_core::hex::get_package_release and records the outer_checksum and dependency names from that JSON response into manifest.toml, instead of the values from the verified repository metadata. The Hex repository signature does not cover the API response.
An adversary in the middle who can intercept TLS with a certificate trusted by the Gleam process (for example a TLS-inspecting proxy using a CA in the operating system trust store or added through GLEAM_CACERTS_PATH), and who can modify both the API release response and the corresponding repository tarball, can supply a package archive with a matching forged checksum without the Hex repository signing key. Gleam verifies the forged tarball against the forged checksum, accepts it, and extracts it as a dependency source, resulting in loss of integrity of the downloaded package contents.
Only projects that resolve or update Hex dependencies are affected, which happens when the manifest is missing, a dependency is added or updated, or dependency requirements change. Builds that reuse an unchanged, known-good manifest.toml continue to verify tarballs against its pinned checksum. This issue affects gleam: from 0.18.0 before 1.18.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
This vulnerability represents a critical failure in Gleam's dependency resolution process where the system improperly validates data authenticity during package installation. The flaw stems from a fundamental mismatch between the cryptographic verification mechanisms applied to repository metadata and the unsigned API responses that follow. When Gleam performs dependency resolution, it correctly verifies package metadata against signature-verified Hex repository contents that include SHA-256 outer_checksum values and dependency requirements. However, the system subsequently makes a second HTTP request to an unsigned Hex API endpoint through the gleam_core::hex::get_package_release function. This second step incorrectly imports data from the unsigned API response directly into manifest.toml without proper verification against the previously validated repository metadata. The vulnerability creates a window where attackers can manipulate both the API response and corresponding tarball contents while maintaining cryptographic consistency through forged checksums.
The technical execution of this attack requires an adversary positioned in the network path with the ability to intercept TLS communications using a certificate trusted by the Gleam process. This could occur through various means including TLS-inspecting proxies that leverage certificates from the operating system trust store or those added via GLEAM_CACERTS_PATH environment variable. The attacker must simultaneously modify both the unsigned Hex API response containing forged dependency names and outer_checksum values, as well as the corresponding tarball contents to match these forged checksums. This attack pattern aligns with common MITM techniques described in the ATT&CK framework under T1041 for data manipulation during transit, and specifically targets the supply chain integrity of package management systems. The vulnerability is classified as CWE-295 - Improper Certificate Validation, which directly enables the attack vector by allowing untrusted certificates to be accepted.
The operational impact of this vulnerability extends beyond simple code injection to represent a complete compromise of software supply chain integrity. When an attacker successfully substitutes forged package contents, they gain the ability to execute arbitrary code within the context of applications that depend on these malicious packages. The vulnerability affects all projects that perform dependency resolution operations, including initial project setup, dependency additions, updates, or requirement changes. However, it should be noted that builds using unchanged manifest.toml files continue to maintain integrity verification against pinned checksums, creating a partial defense mechanism for existing installations. This differential behavior means that organizations with established, stable dependency trees may remain protected while new development activities and dependency modifications become vulnerable attack surfaces.
Mitigation strategies must address both the immediate vulnerability and underlying architectural weaknesses in the dependency resolution process. The most effective approach involves implementing proper validation of API responses against previously verified repository metadata, ensuring that values imported from unsigned sources are properly authenticated through cryptographic means. Organizations should consider updating to Gleam versions 1.18.0 or later where this vulnerability has been addressed, and implement network-level controls such as certificate pinning and strict TLS requirements to prevent unauthorized interception. Additionally, security teams should monitor for potential exploitation attempts through unusual dependency resolution patterns and maintain updated threat intelligence on supply chain attacks targeting package management systems. The fix should enforce that API responses are validated against the repository signature verification process rather than allowing direct import of unsigned data into manifest files.