Skip to main content
VulnerabilityPublished Updated

CVE-2026-59247: gleam · Insufficient Verification of Data Authenticity

Affects gleamSource CVE Database V5

0

Not known to be exploited · CVSS 7.6 High : upgrade to 1.18.0 soon.

Data as of 28 Oct 2026, 05:11 UTC

CVSS 4.0 base score
7.6High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 1.18.0, c9c0d48c123c8abae6db8dd61b25ccb427ed3d35, v1.18.0-scratch +9
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
gleam-langgleamAffected
  • >=0.18.0 <1.18.0
Fixed in
  • 1.18.0
gleam-langgleamAffected
  • >=0.18.0 <1.18.0
Fixed in
  • c9c0d48c123c8abae6db8dd61b25ccb427ed3d35
  • 1.18.0
gleam-langgleamAffected
  • >=0.18.0-elixir <1.18.0-elixir
  • >=0.18.0-elixir-slim <1.18.0-elixir-slim
  • >=0.18.0-elixir-alpine <1.18.0-elixir-alpine
  • >=0.18.0-erlang <1.18.0-erlang
  • >=0.18.0-erlang-slim <1.18.0-erlang-slim
  • >=0.18.0-erlang-alpine <1.18.0-erlang-alpine
  • >=0.18.0-node <1.18.0-node
  • >=0.18.0-node-slim <1.18.0-node-slim
  • >=0.18.0-node-alpine <1.18.0-node-alpine
  • >=1.6.0-scratch <1.18.0-scratch
Fixed in
  • v1.18.0-scratch
  • v1.18.0-node-slim
  • v1.18.0-node-alpine
  • v1.18.0-node
  • v1.18.0-erlang-slim
  • v1.18.0-erlang-alpine
  • v1.18.0-erlang
  • v1.18.0-elixir-slim
  • v1.18.0-elixir-alpine
  • v1.18.0-elixir
GitHubgleam.run/gleampkg:github/gleam.run/gleamOther threatsAffected
  • >=0.18.0 <1.18.0
Fixed in
  • 1.18.0
GitHubgleam-lang/gleampkg:github/gleam-lang/gleamOther threatsAffected
  • >=0.18.0 <1.18.0
Fixed in
  • 1.18.0

CPE configurations (1)

  • cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

If you cannot patch yet, 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.

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.

References

Community reviews

Loading reviews…