Which versions of Gleam are affected by CVE-2026-59247?

The Gleam build tool (compiler-cli) versions 0.18.0 through 1.18.0 contain a package integrity bypass vulnerability that could allow attackers to inject malicious code into applications during the…. A patch is available.

How to fix or mitigate CVE-2026-59247?

Within 24 hours, identify all development systems and CI/CD pipelines running Gleam compiler-cli versions 0.18.0 through 1.18.0 and restrict their use pending patching. Within 7 days, upgrade all affected systems to the patched version available per vendor advisory and verify network controls to prevent man-in-the-middle attacks, including TLS certificate pinning and trusted CA validation for build environments. Within 30 days, conduct a security audit of all software artifacts built during the vulnerable period using affected Gleam versions to assess potential dependency compromise.

Gleam CVE-2026-59247

Q: What is the CVSS score of CVE-2026-59247?

CVE-2026-59247 has a CVSS 4.0 base score of 7.6 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-50362 HIGH

Insufficient Verification of Data Authenticity (CWE-345)

2026-07-29 EEF

Information Disclosure Gleam

7.6

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

7.6 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.8 MEDIUM

Network vector but AC:H reflects the required MITM-with-trusted-CA precondition (AT:P) and UI:R the user-initiated dependency resolution; forged source compromises C and I, no availability impact.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 29, 2026 - 15:18 vuln.today

Analysis Generated

Jul 29, 2026 - 15:18 vuln.today

CVE Published

Jul 29, 2026 - 14:24 cve.org

HIGH 7.6

DescriptionCVE.org

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.

AnalysisAI

Package integrity bypass in the Gleam build tool (compiler-cli) versions 0.18.0 up to 1.18.0 lets an adversary-in-the-middle substitute forged Hex dependency contents during resolution. Although Gleam fetches signature-verified registry metadata, gleam_cli::dependencies::lookup_package instead recorded the SHA-256 outer_checksum and dependency names from a second, unsigned Hex API call into manifest.toml, so the forged tarball validates against its own forged checksum. Exploitation requires an attacker who can both perform TLS interception with a CA trusted by the Gleam process and modify the tarball; there is no public exploit identified at time of analysis and it is not in CISA KEV.

Technical ContextAI

Gleam is a statically typed language for the BEAM (Erlang) virtual machine, and its CLI resolves dependencies from Hex, the Erlang/Elixir package repository. Hex serves two data planes: a signed registry (repository v2 metadata, per hexpm/specifications registry-v2.md) that authenticates each release's dependency requirements and outer_checksum, and a separate unsigned HTTP API. The root cause is CWE-345 (Insufficient Verification of Data Authenticity): the code trusted the unsigned API JSON (via gleam_core::hex::get_package_release) for the checksum and requirements it later used to gate tarball extraction, rather than the signature-verified repository values. Because the Hex repository signing key never covers the API response, the trust anchor was effectively the TLS session - not the package signature. The fix (commit c9c0d48) introduces a VerifiedRelease struct and verified_releases() so the outer_checksum and requirements written to manifest.toml come from the signed hexpm::Package metadata, leaving only build_tools/otp_app (non-security-critical) sourced from the API.

RemediationAI

Vendor-released patch: upgrade Gleam to 1.18.0 or later, which pins the tarball checksum and dependency requirements to the signature-verified registry metadata (fix in commit c9c0d48c123c8abae6db8dd61b25ccb427ed3d35; advisory GHSA-4vvc-458m-r82g). Until you can upgrade, resolve dependencies only from a trusted network and avoid running gleam operations that touch dependency resolution (adding/updating dependencies, changing requirements, or building without a manifest) behind a TLS-inspecting proxy - commit a known-good manifest.toml to source control and reuse it, since builds against an unchanged pinned manifest continue to verify tarballs against the trusted checksum. Do not add untrusted CAs to the OS trust store or point GLEAM_CACERTS_PATH at an interception CA, as that is precisely the trust that this attack abuses; the trade-off is that legitimate corporate TLS-inspection proxies will break Gleam's package fetching, which is the intended safer behavior.