CVE-2026-59247
HighCVSS 7.6Exploitation Probability (EPSS)
Low risk3th percentile - higher than 3% of all known CVEs
Summary
A vulnerability in Gleam allows a man-in-the-middle attacker to substitute forged Hex package contents during dependency resolution due to insufficient verification of data authenticity. The second request to the unsigned Hex API is used instead of verified repository metadata.
Risk Assessment
The organization is at risk of malicious code injection through package substitution, potentially leading to application integrity compromise and system takeover.
Recommendation
Update Gleam to version 1.18.0 or later immediately. Until then, use only trusted manifests and avoid dependency resolution in environments with untrusted TLS.
Other vulnerabilities in Gleam
See all- CVE-2026-43965Medium
Path traversal vulnerability in Gleam's dependency management (versions 0.18.0-rc1 through 1.17.0) allows arbitrary directory deletion via malicious build/packages/packages.toml content. Package keys are used without validation to construct paths, allowing ../ sequences to escape the intended directory.
- CVE-2026-42795Medium
A symlink following vulnerability in Gleam's Hex package export allows files outside the project root to be embedded in the generated package tarball. File collection helpers use follow_links(true) when walking publishable directories, and paths are added to the archive without verifying that the resolved target remains within the project root.
- CVE-2026-32685Medium
Path traversal vulnerability in Gleam's custom documentation pages handling (versions 1.16.0 through 1.17.0) allows arbitrary file read and write outside the intended documentation output directory. The documentation.pages[].path and .source fields are used without sufficient validation.
- CVE-2026-32146High
A path validation vulnerability in the Gleam compiler's handling of git dependencies allows arbitrary file system modification during dependency download. Dependency names from gleam.toml and manifest.toml are used in filesystem paths without sufficient validation, enabling path traversal (e.g., ../) to access files outside the intended dependency directory. A malicious dependency can delete or overwrite arbitrary directories, potentially leading to data loss or code execution.
Original NVD description (English source)
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.