{"id":"CVE-2026-59247","aliases":["EEF-CVE-2026-59247","EUVD-2026-50362","GHSA-4vvc-458m-r82g","openSUSE-SU-2026:11462-1","openSUSE-SU-2026:21557-1"],"status":"published","title":"Insufficient verification of Hex package metadata in 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.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.\n\nThis issue affects gleam: from 0.18.0-rc1 before 1.18.0.","severity":{"version":"4.0","score":7.6,"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00182,"percentile":0.07853,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-345"],"published":"2026-07-29T14:24:55Z","modified":"2026-11-10T20:19:28Z","fixes":[{"ecosystem":"openSUSE:Tumbleweed","package":"gleam","fixed_in":["1.18.1-1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 16.0","package":"gleam","fixed_in":["1.18.1-bp160.1.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"gleam","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.18.1-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"gleam","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.18.1-bp160.1.1"}]}]}],"products":[{"vendor":"gleam","product":"gleam"}],"references":[{"url":"https://github.com/gleam-lang/gleam/security/advisories/GHSA-4vvc-458m-r82g","tags":["vendor-advisory","related","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-59247.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-59247","tags":["related","web"]},{"url":"https://github.com/hexpm/specifications/blob/main/registry-v2.md","tags":["related","web"]},{"url":"https://github.com/gleam-lang/gleam/commit/8447b78cc844ff4aec44eea23dbd68d1fea11f11","tags":["related","web"]},{"url":"https://github.com/gleam-lang/gleam/commit/c9c0d48c123c8abae6db8dd61b25ccb427ed3d35","tags":["patch","fix"]},{"url":"https://ghcr.io","tags":["web"]},{"url":"https://github.com","tags":["web"]},{"url":"https://gleam.run","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/59xxx/CVE-2026-59247.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59247","tags":["advisory"]},{"url":"https://github.com/gleam-lang/gleam","tags":["package"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59247","tags":["web"]},{"url":"https://bugzilla.suse.com/1272992","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-59247","title":"Insufficient verification of Hex package metadata in 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.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.\n\nThis issue affects gleam: from 0.18.0-rc1 before 1.18.0.","status":"published","published":"2026-07-29T14:24:55.499Z","modified":"2026-11-10T19:18:20.583Z","cvss":[{"version":"4.0","score":7.6,"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","level":"high","assessor":"cna"}],"cwes":["CWE-345"],"updated_at":"2026-11-10T22:18:27.902968Z"}],"euvd":[{"id":"EUVD-2026-50362","description":"Insufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package contents during dependency resolution.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.\n\nThis issue affects gleam: from 0.18.0-rc1 before 1.18.0.","status":"published","published":"2026-07-29T14:24:55Z","modified":"2026-11-10T19:18:20Z","cvss":[{"version":"4.0","score":7.6,"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","level":"high"}],"updated_at":"2026-11-10T20:23:05.996887Z"}],"nvd":[{"id":"CVE-2026-59247","description":"Insufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package contents during dependency resolution.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.\n\nThis issue affects gleam: from 0.18.0-rc1 before 1.18.0.","status":"published","published":"2026-07-29T15:16:26.78Z","modified":"2026-11-10T20:19:28.443Z","cvss":[{"version":"4.0","score":7.6,"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","level":"high","assessor":"secondary"}],"cwes":["CWE-345"],"updated_at":"2026-11-10T22:21:28.929083Z"}],"osv":[{"id":"CVE-2026-59247","title":"Insufficient verification of Hex package metadata in 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.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.","status":"published","published":"2026-07-29T14:24:55.499Z","modified":"2026-10-28T02:30:57.694615582Z","cvss":[{"version":"4.0","score":7.6,"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","level":"high"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T15:45:12.496548Z"},{"id":"EEF-CVE-2026-59247","title":"Insufficient verification of Hex package metadata in Gleam","description":"## Summary\n\nInsufficient Verification of Data Authenticity vulnerability in Gleam allows an adversary in the middle to substitute forged Hex package contents during dependency resolution.\n\nDuring 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.\n\nAn 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.\n\nOnly 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.\n\nThis issue affects gleam: from 0.18.0-rc1 before 1.18.0.","status":"published","published":"2026-07-29T14:24:55.499Z","modified":"2026-11-10T19:30:02.834724583Z","cvss":[{"version":"4.0","score":7.6,"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","level":"high"}],"cwes":["CWE-345"],"updated_at":"2026-11-10T19:36:39.929043Z"},{"id":"openSUSE-SU-2026:11462-1","title":"gleam-1.18.1-1.1 on GA media","description":"These are all security issues fixed in the gleam-1.18.1-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-06T00:00:00Z","modified":"2026-08-07T10:00:44.710197338Z","updated_at":"2026-11-02T16:58:39.516824Z"},{"id":"openSUSE-SU-2026:21557-1","title":"Security update for gleam","description":"This update for gleam fixes the following issues:\n\nChanges in gleam:\n\n- Update to 1.18.1:\n  * CVE-2026-59247: insufficient verification of data authenticity\n    allows a MITM adversary to substitute forged Hex package\n    contents during dependency resolution (bsc#1272992)\n  * Set minimum required Erlang version to 26\n  * All features and bug fixes are extensively highlighted with\n    examples in upstream's blog post at\n    https://gleam.run/news/a-field-day-for-gleams-language-server/\n    and changelog at\n    https://github.com/gleam-lang/gleam/blob/v1.18.1/CHANGELOG.md .\n    Some of the highlights include:\n      - A lot of new features for the LSP\n      - Faster JavaScript using singletons\n      - Deprecation of ambiguous pipe syntax\n      - Path support in Git dependencies\n      - Up to 13% faster compilation\n      - Fixed various bugs in Erlang and JavaScript code\n        generation.\n      - Fixed several bugs in the float handling for the JavaScript\n        target.\n      - Fixed a bug in the generation of Erlang .app files.\n      - Fixed a bug where the formatter would produce invalid code.\n      - Fixed a bug in the TypeScript type definition generation.\n      - Fixed a bug where the compiler would evaluate the numerator\n        and denominator of a division in the wrong order.\n      - Fixed a bug where gleam docs would not be generated.\n","status":"published","published":"2026-08-10T10:55:07Z","modified":"2026-08-12T18:23:42.474465357Z","updated_at":"2026-11-02T16:58:41.885092Z"}]}}