CVE-2026-59247: CWE-345 Insufficient Verification of Data Authenticity in gleam-lang gleam
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.
AI Analysis
Technical Summary
CVE-2026-59247 describes an insufficient verification of data authenticity vulnerability in Gleam affecting versions 0.18.0 through before 1.18.0. Gleam initially obtains package metadata from a signature-verified Hex repository, which includes dependency requirements and SHA-256 checksums. However, during dependency resolution, Gleam makes a second request to an unsigned Hex API endpoint to retrieve package release information, recording the outer_checksum and dependency names from this unsigned response into manifest.toml. Since the Hex repository signature does not cover this API response, an attacker capable of intercepting TLS traffic with a trusted certificate (e.g., via a TLS-inspecting proxy with a trusted CA) can modify both the API response and the corresponding package tarball. By supplying a forged package archive with a matching checksum, Gleam verifies and accepts the malicious package, resulting in compromised package integrity. This vulnerability only affects projects that resolve or update Hex dependencies; builds that reuse an unchanged manifest.toml continue to verify tarballs against pinned checksums and are not affected.
Potential Impact
An attacker with the ability to intercept TLS traffic trusted by the Gleam process can supply forged package contents during dependency resolution, causing Gleam to accept and extract malicious package source code. This compromises the integrity of dependencies, potentially leading to execution of malicious code in affected projects. The vulnerability does not affect builds that reuse an unchanged manifest.toml, as these verify packages against pinned checksums from the verified repository metadata.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, avoid resolving or updating Hex dependencies in untrusted network environments where TLS interception with trusted certificates is possible. Reusing an unchanged, known-good manifest.toml mitigates the risk by ensuring verification against pinned checksums. Monitor official Gleam project communications for updates and apply any official fixes once released.
CVE-2026-59247: CWE-345 Insufficient Verification of Data Authenticity in gleam-lang gleam
Description
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.
CVSS v4.0
Score 7.6high
Affected software
pkg:github/gleam.run/gleamcpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-59247 describes an insufficient verification of data authenticity vulnerability in Gleam affecting versions 0.18.0 through before 1.18.0. Gleam initially obtains package metadata from a signature-verified Hex repository, which includes dependency requirements and SHA-256 checksums. However, during dependency resolution, Gleam makes a second request to an unsigned Hex API endpoint to retrieve package release information, recording the outer_checksum and dependency names from this unsigned response into manifest.toml. Since the Hex repository signature does not cover this API response, an attacker capable of intercepting TLS traffic with a trusted certificate (e.g., via a TLS-inspecting proxy with a trusted CA) can modify both the API response and the corresponding package tarball. By supplying a forged package archive with a matching checksum, Gleam verifies and accepts the malicious package, resulting in compromised package integrity. This vulnerability only affects projects that resolve or update Hex dependencies; builds that reuse an unchanged manifest.toml continue to verify tarballs against pinned checksums and are not affected.
Potential Impact
An attacker with the ability to intercept TLS traffic trusted by the Gleam process can supply forged package contents during dependency resolution, causing Gleam to accept and extract malicious package source code. This compromises the integrity of dependencies, potentially leading to execution of malicious code in affected projects. The vulnerability does not affect builds that reuse an unchanged manifest.toml, as these verify packages against pinned checksums from the verified repository metadata.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, avoid resolving or updating Hex dependencies in untrusted network environments where TLS interception with trusted certificates is possible. Reusing an unchanged, known-good manifest.toml mitigates the risk by ensuring verification against pinned checksums. Monitor official Gleam project communications for updates and apply any official fixes once released.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-07-04T04:24:03.652Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a6a13c09c2644c7f8a6d81a
Added to database: 07/29/2026, 14:52:48 UTC
Last enriched: 07/29/2026, 15:08:15 UTC
Last updated: 07/30/2026, 00:44:34 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.