Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums.

Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected.

An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering.

This issue affects hex: from 0.16.0 before 2.4.2.
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Thu, 30 Apr 2026 19:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Thu, 30 Apr 2026 19:00:00 +0000

Type Values Removed Values Added
Description Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums. Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected. An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering. This issue affects hex: from 0.16.0 before 2.4.2.
Title Lockfile checksums not verified in Hex allows dependency integrity bypass
First Time appeared Hexpm
Hexpm hex
Weaknesses CWE-354
CWE-494
CPEs cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*
Vendors & Products Hexpm
Hexpm hex
References
Metrics cvssV4_0

{'score': 8.9, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H'}


Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-04-30T19:03:24.858Z

Reserved: 2026-03-10T22:37:29.213Z

Link: CVE-2026-32148

cve-icon Vulnrichment

Updated: 2026-04-30T19:03:21.319Z

cve-icon NVD

Status : Received

Published: 2026-04-30T19:16:09.000

Modified: 2026-04-30T20:16:23.673

Link: CVE-2026-32148

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-04-30T21:00:14Z

Weaknesses