CyberSecBulletin
CVE-2026-59247NVD status: Deferred

Gleam: Insufficient Verification of Data Authenticity

Published Updated By the CyberSecBulletin desk

CVE-2026-59247 is a high-severity insufficient verification of data authenticity vulnerability in Gleam, with a CVSS 4.0 base score of 7.6 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, but only if a user takes part, for example by opening a link or file. The record lists versions 1.18.0, v1.18.0-elixir, v1.18.0-erlang as the first without the flaw, so updating Gleam to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.2% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Gleam to 1.18.0 or v1.18.0-elixir or v1.18.0-erlang or v1.18.0-node, whichever matches your release line, or a later version.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
  4. Because the attack needs a user to take part, warn users about unexpected links and files related to this product until it is patched.

Affected products and versions

VendorProductAffected versionsFixed in
GleamGleam0.18.0-rc1 up to, but not including, 1.18.0; v0.18.0-rc1-elixir up to, but not including, v1.18.0-elixir; v0.18.0-rc1-erlang up to, but not including, v1.18.0-erlang; v0.18.0-rc1-node up to, but not including, v1.18.0-node; v0.18.0-rc1-node-slim up to, but not including, v1.18.0-node-slim; v0.18.0-rc1-elixir-slim up to, but not including, v1.18.0-elixir-slim; v0.18.0-rc1-erlang-slim up to, but not including, v1.18.0-erlang-slim; v0.18.0-rc1-erlang-alpine up to, but not including, v1.18.0-erlang-alpine; and 4 more ranges1.18.0, v1.18.0-elixir, v1.18.0-erlang, v1.18.0-node, v1.18.0-node-slim, v1.18.0-elixir-slim

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Attack requirements
PresentThe target must be in a specific state or configuration for the attack to work.
Privileges required
NoneNo account or login is needed.
User interaction
PassiveA user only needs to do something routine, such as viewing a page.
Confidentiality (vulnerable system)
HighSerious loss of confidentiality on the vulnerable system.
Integrity (vulnerable system)
HighSerious loss of integrity on the vulnerable system.
Availability (vulnerable system)
NoneNo loss of availability on the vulnerable system.
Confidentiality (other systems)
NoneNo loss of confidentiality on systems beyond the vulnerable one.
Integrity (other systems)
NoneNo loss of integrity on systems beyond the vulnerable one.
Availability (other systems)
NoneNo loss of availability on systems beyond the vulnerable one.

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. Scored by CNA.

Official 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-rc1 before 1.18.0.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Insufficient Verification of Data Authenticity

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

More Insufficient Verification of Data Authenticity vulnerabilities (CWE-345)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in Gleam

All Gleam vulnerabilities

Recent Insufficient Verification of Data Authenticity vulnerabilities

Spotted an error? Tell us.