CVE-2026-32148
Insufficient Verification of Data Authenticity in Hex
Publication date: 2026-04-30
Last updated on: 2026-05-05
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| hex | hex | From 0.16.0 (inc) to 2.4.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-494 | The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code. |
| CWE-354 | The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-32148 is a vulnerability in the Hex package manager for Erlang that affects versions from 0.16.0 up to but not including 2.4.2. The issue arises because the checksum verification for dependencies recorded in the mix.lock file is not properly executed. This happens due to a type mismatch: the lock data uses string-based dependency names, while the verification logic expects atom-based names. Because of this mismatch, the checksum verification code is silently skipped.
As a result, although checksums are validated when packages are initially downloaded from the registry, mismatches between the lockfile and resolved dependencies are not detected during dependency resolution. This allows an attacker who can influence cached packages (for example, via local cache poisoning or a compromised registry) to provide modified dependency contents that will be accepted without detection. Furthermore, the mix.lock file is silently rewritten with checksum values from the registry, erasing evidence of tampering.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker to bypass dependency integrity checks in the Hex package manager. If an attacker can manipulate cached packages or compromise the package registry, they can supply modified or tampered dependencies that will be accepted without detection.
This means that your builds may include malicious or altered code without any warning or error, potentially compromising the confidentiality, integrity, and availability of your systems. The mix.lock file, which is supposed to guarantee reproducible and integrity-checked builds, will silently update to reflect the attacker's tampered checksums, masking the attack.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the silent skipping of checksum verification in Hex package manager versions from 0.16.0 before 2.4.2, due to a type mismatch in dependency names during verification. Detection involves verifying whether your Hex installation is within the affected version range and checking if the mix.lock file's checksums are properly enforced.
Since the vulnerability causes the mix.lock file to be silently rewritten with registry checksum values without raising errors, one way to detect it is to monitor changes to the mix.lock file after running dependency commands like `mix deps.get`.
- Check Hex version: `mix hex.info` or `mix hex.version` to confirm if your version is >= 0.16.0 and < 2.4.2.
- Manually inspect the mix.lock file before and after running `mix deps.get` for unexpected checksum changes.
- Use version control diff tools (e.g., `git diff mix.lock`) after dependency resolution commands to detect silent rewrites.
There are no specific built-in commands or automated detection tools mentioned in the resources for this vulnerability, so detection relies on version checks and monitoring lockfile integrity manually.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade the Hex package manager to version 2.4.2 or later, where the checksum verification logic has been corrected to properly enforce lockfile integrity.
Until upgrading, avoid using affected Hex versions (>= 0.16.0 and < 2.4.2) in production environments, especially if you rely on the lockfile for dependency integrity guarantees.
Be cautious of potential local cache poisoning or compromised registries, as these attack vectors can exploit this vulnerability.
- Upgrade Hex to version 2.4.2 or newer.
- Audit and verify your mix.lock file integrity after upgrading.
- Consider clearing local Hex caches to prevent use of potentially poisoned cached packages.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability weakens the integrity guarantees of the Hex package manager's lockfile mechanism, which is intended to ensure that the exact, audited dependency set is used. Because checksum verification is bypassed, tampered or malicious dependencies can be introduced without detection.
Such a flaw can increase the risk of executing untrusted or altered code, potentially leading to unauthorized access, data breaches, or system compromise.
Consequently, this undermines the ability to maintain secure and trusted software supply chains, which is a critical aspect of compliance with standards and regulations like GDPR and HIPAA that require protection of data integrity and confidentiality.
While the CVE description and resources do not explicitly mention specific compliance impacts, the reduced assurance in dependency integrity can negatively affect adherence to these regulations by increasing the risk of data exposure or unauthorized system changes.