CVE WatchJul 29, 2026

CVE-2026-59247

Insufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package con

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Jul 29, 2026 · Last modified: Jul 29, 2026 · CWE-345

EPSS · 30d

Not enough EPSS history yet.

Technical 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.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-123837.5 HIG

2.8%

——1A flaw was found in the Event-Driven Ansible (EDA) server. The ExternalEventStreamViewSet uses permissive access controls (permission_classes=[AllowAny], authentication_classes=[]) and relies solely on the Subject HTTP header value for mTLS authentication without verifying that the header originated from a trusted proxy. Additionally, the expected certificate Distinguished Name is leaked in the 403 error response body. An attacker who can reach the EDA API endpoint with a spoofed Subject header can inject arbitrary events into mTLS-protected event streams, triggering downstream automation actions.2d CVE-2026-391556.5 MED

4.6%

——1Knot DNS before 3.4.10 and 3.5.x before 3.5.4 contains a vulnerability in mod-onlinesign where the next NSEC owner name can be computed incorrectly. This can create an overly broad authenticated denial interval, allowing downstream validating resolvers using aggressive negative caching to synthesize negative answers for legitimate names and causing resolver-side denial of service.5d CVE-2026-156157.5 HIG

8.1%

——2Logto omits validation of the SAML <Conditions> element, enabling attackers to strip time and audience restrictions and replay assertions indefinitely.2d CVE-2026-156129.1 CRI

8.1%

——2Logto bypasses OIDC nonce validation when the nonce claim is absent from the id_token, enabling replay of authentication tokens and weakening session-binding.2d CVE-2026-526887.5 HIG

2.7%

——1RRSIGs with too few labels can lead to bypass of DNSSEC wildcard validation6d CVE-2026-502486.5 MED

3.2%

——1In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when an auth/rpz zone has a configured primary hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint. A malicious actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary and can replaces the entire zone/the resolver's entire response policy.5d