Lockfile checksums not verified in Hex allows dependency integrity bypass
Severity and exploitation
KEV coverage does not rule out exploitation.
Assessment 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:HSeverity
high8.9CVSS measures technical severity, not the likelihood of an attack.
Known exploitation
Not listed in the checked CISA KEV catalog
Absence from CISA KEV does not rule out attacks.
Public exploit
Exploit reference published
Source-linked evidence; not proof of attacks in the wild or independent validation.
Remediation
Fix status not established
No structured fix or guidance is available here. Check the latest publisher advisory.
What this means
Hex versions from 0.16.0 before 2.4.2 have an Insufficient Verification of Data Authenticity vulnerability, allowing dependency integrity bypass via unverified lockfile checksums. An attacker with influence over cached packages can provide modified dependencies that will be accepted without detection. The issue is due to a type mismatch in the verification logic.
Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.Attack conditions
No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.
Review supporting sources →Affected versions
Check the exact model, release, and any platform requirements against your installation.
hexpm · EEF
hex
1 range
hexpm · EEF
hex
Package identity
pkg:otp/hex?repository_url=https:%2F%2Fgithub.com%2Fhexpm%2Fhex&vcs_url=git%2Bhttps:%2F%2Fgithub.com%2Fhexpm%2Fhex.gitIdentity supplied by EEF. Version matching requires compatible range evidence.
Compare with this publisher’s ranges. This does not inspect your installation.
affected
0.16.0 → before 2.4.2
semver versions
Other versions: unaffected
Product identifiers (CPE)
cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*hexpm · EEF
hex
1 range
hexpm · EEF
hex
Package identity
pkg:github/hexpm/hexIdentity supplied by EEF. Version matching requires compatible range evidence.
Compare with this publisher’s ranges. This does not inspect your installation.
affected
e01576f28c64af9fae6eb17e2dad30f6efcb303c → before d7528c8199a1144511508bf3a6460026a5a14c8e
git versions
Other versions: unaffected
Product identifiers (CPE)
cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*What to do
Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.
No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.
cve.new guidance unless attributed to a publisher. This page does not inspect your installation.
Public exploit evidence
The sources identify public exploit references. We have not independently tested them; their availability does not establish exploitation in the wild.
hexpm/hex · security/advisories/GHSA-hmv9-4mfr-m92v ↗Attributed to CISA-ADPOriginal source description
Read the full publisher 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.
References
5 sourcesInside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-32148View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Environment requirements
These conditions apply together as specified by the publisher. A matching product name alone does not establish exposure.
EEF · platform conditions
All conditions must hold
Any condition may hold
Vulnerable product
cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*From (inclusive): 0.16.0
Before: 2.4.2
Applicability preview
[
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.4.2",
"versionStartIncluding": "0.16.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
]Contributing organizations · 2
Assigning organization
Additional data publisher
Timeline
All times UTCAdvisory published
Publication date supplied by the source.
Source updated
Latest modification date supplied by the source.
Last imported by cve.new
Latest catalog import, not the date we first saw this advisory.
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.