Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconGain cache write access or MitM position
-
DeliveryIntercept 'mix deps.get' request
-
ExploitServe malicious package with valid registry metadata
-
InstallType mismatch silently bypasses checksum verification
-
C2Malicious dependency accepted and cached
-
Executemix.lock silently rewritten with attacker checksums
-
ImpactBackdoored code executes during build/runtime
-
Step 8Supply chain compromise achieved
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Integrity verification
|
| Exploitation Conditions | Exploitation requires the attacker to control or influence package content during dependency resolution - either by (1) writing to the local Hex package cache directory (typically ~/.hex/packages/) on the victim's development machine or CI/CD runner, which requires prior local access or malware deployment, or (2) intercepting and modifying network traffic between the Hex client and hex.pm registry during 'mix deps.get' execution through man-in-the-middle positioning (requires network-level access such as compromised WiFi, DNS hijacking, or BGP manipulation), or (3) compromising upstream Hex registry infrastructure or mirrors to serve malicious packages. The attack window is limited to when developers execute dependency resolution commands (AT:P - Attack Timing: Precise). User must actively invoke Mix commands that trigger dependency fetching (UI:A), such as 'mix deps.get', 'mix deps.update', or initial project setup. The vulnerability does NOT affect builds using pre-existing validated lockfiles without re-resolving dependencies. Organizations using private, integrity-verified Hex mirrors with network egress restrictions significantly reduce attack surface. Exploitation is non-automatable (SSVC: Automatable=no) due to requirement for precise timing coordination and user-initiated dependency resolution. |
| Impact | CVSS 4.0 score of 8.9 reflects high confidentiality, integrity, and availability impact with network attack vector (AV:N), low complexity (AC:L), but requires precise timing (AT:P) and user interaction (UI:A). However, real-world risk requires careful context assessment. SSVC indicates proof-of-concept exists and technical impact is total, but exploitation is NOT automatable - attacker must coordinate cache poisoning or registry compromise with developer dependency installation timing. The attack requires either (1) local cache write access on developer machines or CI/CD systems, or (2) compromise of the Hex registry or mirror infrastructure during package resolution. The CVSS vector's AT:P (Attack Timing: Precise) and UI:A (User Interaction: Active) significantly constrain mass exploitation scenarios. For organizations using private Hex mirrors or with strict network egress controls, risk is lower. For supply chain security contexts where attackers target high-value projects and can conduct sustained infrastructure compromise campaigns, this represents critical risk due to silent failure mode - no error messages alert developers to tampered dependencies. The silent lockfile rewrite erases forensic evidence, making post-compromise detection extremely difficult. Prioritize patching in CI/CD pipelines and developer workstations for projects in regulated or high-security contexts. |
| Exploit ScenarioDerived | An attacker compromises a developer's local package cache directory or injects malicious responses into network traffic between the developer workstation and hex.pm registry (e.g., via DNS spoofing or BGP hijacking). When the developer runs 'mix deps.get', Hex retrieves dependency metadata but the type mismatch causes checksum verification to silently fail. The attacker's modified package (containing backdoored code) is accepted, and mix.lock is automatically rewritten with checksums from the attacker-controlled source, erasing evidence of tampering. The malicious dependency executes during compilation or runtime, achieving supply chain compromise. SSVC indicates proof-of-concept code demonstrating the checksum bypass exists, making exploitation feasible for sophisticated threat actors targeting high-value Elixir projects. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 30, 2026
Silent dependency checksum bypass in hexpm/hex package manager (versions 0.16.0 through 2.4.1) allows attackers to substitute malicious dependencies without detection. The Hex.RemoteConverger module fails to verify lockfile checksums due to a string-versus-atom type mismatch in the verification logic, causing the security check to be silently skipped. Attackers who can poison local package caches or compromise registry responses can deliver modified packages that overwrite mix.lock without raising alerts. SSVC framework indicates proof-of-concept exists, attack is non-automatable (requires user interaction and precise timing), with total technical impact. Fixed in version 2.4.2 (commit d7528c8).
RemediationAI
Upgrade hexpm/hex to version 2.4.2 or later, which implements correct string-based name comparison in Hex.RemoteConverger.verify_resolved/2 (commit d7528c8199a1144511508bf3a6460026a5a14c8e at https://github.com/hexpm/hex/commit/d7528c8199a1144511508bf3a6460026a5a14c8e). For Elixir projects, update via 'mix local.hex --force' or 'mix archive.install hex hex-2.4.2.ez'. Immediately after upgrading, regenerate mix.lock files by deleting existing lockfiles and running 'mix deps.get' to ensure checksums are freshly validated under corrected logic. If immediate patching is blocked, implement compensating controls: restrict network access to official hex.pm registry only (block alternate registries and local mirrors unless cryptographically verified), implement file integrity monitoring on _build/ and deps/ directories to detect unexpected package modifications (alert on checksum changes outside approved deployment windows), use hash pinning in infrastructure-as-code for critical dependencies as secondary validation layer, and enable audit logging for all mix.lock modifications in version control with mandatory code review. Note that workarounds significantly increase operational overhead and do not prevent the silent failure mode - patching to 2.4.2 is strongly recommended over compensating controls.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Hex is the package manager for the Erlang/Elixir ecosystem, integrated with Mix (Elixir's build tool). The vulnerability resides in the Hex.RemoteConverger module responsible for dependency resolution and verification. The root cause (CWE-354: Improper Verification of Integrity Check Value) stems from a data type inconsistency: Hex.Utils.lock/1 returns dependency names as strings, while Hex.RemoteConverger.verify_resolved/2 pattern-matches against atom-based names using the ^atom_name guard. This type mismatch prevents the pattern match from succeeding, silently bypassing checksum validation logic that would otherwise compare mix.lock checksums against registry-provided values. While initial package downloads are checksum-verified against the registry, subsequent builds relying on cached packages or manipulated lockfiles skip this critical integrity check. The commit diff shows the fix converts String.to_atom(name) to direct string comparison and adds comprehensive regression tests that verify checksum mismatch detection.
Know when Hexpm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Primary rating from Vendor (EEF) · only source for this CVE.
CVSS VectorVendor: EEF
Lifecycle Timeline
3DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-32148 affects the Hex package manager (versions 0.16.0-2.4.1) and enables attackers to silently inject malicious dependencies into Elixir/Erlang projects by bypassing lockfile checksum verification. Organizations using vulnerable Hex versions face supply chain compromise risk, where developers may unknowingly pull compromised packages into production builds without detection. This vulnerability requires immediate patching to prevent dependency poisoning attacks that could affect all downstream applications.
Vendor-released patch: version 2.4.2. Until patched, mitigate by: (1) restricting network access to trusted package registries only; (2) implementing build pipeline verification requiring signed commits and lock file validation; (3) running dependency builds in isolated environments with read-only cache; (4) conducting manual spot-checks of mix.lock file integrity before deployment.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Insufficient session expiration in hexpm. Password reset tokens never expire, enabling persistent account takeover.
Improper input sanitization in hexpm's SharedAuthorizationView module allows unauthenticated attackers to inject malicio
Incorrect authorization in the hex.pm OAuth `client_credentials` endpoint allows any API key bearing the `repositories`
Path traversal in the Hex package manager for the Elixir/Erlang (Mix) ecosystem, versions 0.6.0 through 2.5.1, lets a ma
Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protecti
An uncontrolled resource consumption vulnerability in the Hex.pm package manager allows authenticated attackers to cause
Hexpm's OAuth implementation fails to enforce read-only API key restrictions during token exchange, allowing an attacker
Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror
Path traversal in hexpm's Local Storage backend allows unauthenticated attackers to read sensitive files through relativ
Improper TLS server-certificate validation in hex_core (0.1.0 through versions before 0.20.0) lets an attacker who alrea
Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows
Denial of service in Erlang OTP's stdlib erl_tar module (OTP 29.0 before 29.1.2, stdlib 8.0 before 8.1.1) allows an atta
EUVD-2026-26404
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB