gleam-lang gleam up to 1.17.x Dependency Resolution manifest.toml lookup_package data authenticity
| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 6.1 | $0-$5k | 2.37 |
Summary
A vulnerability, which was classified as critical, was found in gleam-lang gleam up to 1.17.x. Affected by this issue is the function gleam_cli::dependencies::lookup_package of the file manifest.toml of the component Dependency Resolution. Such manipulation leads to data authenticity.
This vulnerability is documented as CVE-2026-59247. The attack can be executed remotely. There is not any exploit available.
Details
A vulnerability, which was classified as critical, has been found in gleam-lang gleam up to 1.17.x. Affected by this issue is the function gleam_cli::dependencies::lookup_package of the file manifest.toml of the component Dependency Resolution. The manipulation with an unknown input leads to a data authenticity vulnerability. Using CWE to declare the problem leads to CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Impacted is confidentiality, integrity, and availability. CVE summarizes:
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.
The advisory is shared for download at github.com. This vulnerability is handled as CVE-2026-59247 since 07/04/2026. The exploitation is known to be easy. The attack may be launched remotely. No form of authentication is required for exploitation. Successful exploitation requires user interaction by the victim. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 07/29/2026).
There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Product
Vendor
Name
Version
Website
- Product: https://github.com/gleam-lang/gleam/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 6.3VulDB Meta Temp Score: 6.1
VulDB Base Score: 6.3
VulDB Temp Score: 6.1
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Data authenticityCWE: CWE-345
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: no mitigation knownStatus: 🔍
0-Day Time: 🔒
Timeline
07/04/2026 CVE reserved07/29/2026 Advisory disclosed
07/29/2026 VulDB entry created
07/29/2026 VulDB entry last update
Sources
Product: github.comAdvisory: github.com
Status: Not defined
CVE: CVE-2026-59247 (🔒)
GCVE (CVE): GCVE-0-2026-59247
GCVE (VulDB): GCVE-100-384176
Entry
Created: 07/29/2026 17:05Changes: 07/29/2026 17:05 (55)
Complete: 🔍
Cache ID: 216::103
VulDB is the best source for vulnerability data and more expert information about this specific topic.
No comments yet. Languages: en.
Please log in to comment.