Hex lockfile checksum enforcement silently bypassed since 0.16.0

TL;DR - Hex.RemoteConverger.verify_resolved/2 never actually runs checksum verification. An atom-vs-string type mismatch causes the check to be skipped silently, so mix.lock cannot catch mismatched dependency contents. Worse, the lockfile can be quietly rewritten with registry-supplied checksums, erasing any tamper evidence. Update hex to 2.4.2.

What happened

hex is the package manager for Elixir (and often Erlang) projects. It resolves and fetches dependencies and records expected checksums in mix.lock. That lockfile is a foundational supply-chain control - the thing CI trusts to prove a dependency hasn't changed.

CVE-2026-32148 breaks that guarantee. The Hex.RemoteConverger.verify_resolved/2 function is supposed to confirm that resolved dependency contents match what mix.lock recorded. It never does. The bug is a type mismatch: Hex.Utils.lock/1 returns dependency names as strings, but the verification logic compares against atom-keyed names. That mismatch causes the verification path to be skipped entirely, every time.

Note what this is and isn't. Checksums are still validated when packages are initially downloaded - this is not a wire-level tampering issue. The break is in the post-resolution integrity check: mismatches between the lockfile and the resolved dependency contents go undetected. And mix.lock can be silently rewritten with checksum values from the registry, which means evidence of prior tampering disappears.

Lockfiles are most trusted in CI - exactly where this matters most. If the resolver skips checksum enforcement, pinned dependencies stop being a reliable tamper signal.

Who is impacted

• Any environment running hex versions >= 0.16.0 and < 2.4.2.
• Highest concern where dependency caches can be influenced: shared CI runners, developer workstations, shared build cache volumes.
• CI/CD pipelines that treat mix.lock as a primary integrity and reproducibility boundary.
• Teams already questioning registry trust or operating in high-assurance build environments.

What to do now

• Update hex to 2.4.2 or later on every surface where it runs:
  • developer workstations
  • CI runners and build images
  • shared build hosts
• Treat this as an integrity-control failure and scope accordingly:
  • review dependency cache locations and access controls
  • if you suspect cache poisoning or shared-host compromise, clear caches and re-resolve dependencies from a known-good environment
• If you operate high-trust build pipelines, tighten policy while rolling out the fix:
  • minimise sharing of dependency caches across trust boundaries
  • ensure builds run with least-privilege filesystem access, especially on shared runners

Additional Information

• GitHub security advisory: https://github.com/hexpm/hex/security/advisories/GHSA-hmv9-4mfr-m92v
• Patch commit: https://github.com/hexpm/hex/commit/d7528c8199a1144511508bf3a6460026a5a14c8e
• ERL-EF CNA page: https://cna.erlef.org/cves/CVE-2026-32148.html