hexpm Hex EUVD-2026-97503

Exploitation requires that the attacker already hold package-owner permission on the target package (or have taken over an owner's account) - this is not an unauthenticated flaw. It further requires that (1) a release of that package be locked in the victim's mix.lock, (2) local cooldown be enabled via the cooldown config / HEX_COOLDOWN environment variable, (3) the attacker publish a malicious release and then retire the currently-locked release (or that release carry a security advisory), triggering build_cooldown_bypass/3 and unsafe_lock_bypass/1, and (4) the victim run a mix deps.update that unlocks the package. Limiting factors that reduce real-world risk: owner-level privilege is mandatory, victim action (deps.update) is required, only Hex versions 2.5.0 up to (not including) 2.5.2 are affected, and cooldown configured through an organization dependency policy is NOT affected. A secondary condition broadens impact: because Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, the bypass also lifts cooldown for same-named packages in other repositories.

This is a real but conditional supply-chain weakness (CWE-693 Protection Mechanism Failure) rather than a broadly dangerous remote flaw. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:H) scores 7.1 but is heavily gated: PR:H means the attacker must already be a package owner (or have hijacked an owner's account), AT:P flags a required precondition (a release of that package must be locked in the victim's mix.lock and then retired/advisoried), and UI:A means a victim must actively run mix deps.update. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit code was supplied - so there is no public exploit identified at time of analysis. The high VC/VI/VA (full code-execution-grade compromise of the consuming build) is what pushes severity up, but the prerequisite of owner-level privilege plus victim action makes this a targeted, not opportunistic, threat. One signal worth noting: the cross-repository aspect (Hex.Registry.Cooldown.versions/2 keys the bypass by package name alone, so the bypass also lifts cooldown for same-named packages in other repositories) meaningfully widens blast radius beyond the single malicious package. Net: priority for organizations relying on Hex cooldown as a defense-in-depth control against compromised maintainers, but lower urgency for those using organization dependency policy cooldown, which is explicitly unaffected.

An attacker who controls a package (legitimate owner or via account takeover) publishes a malicious new release, then retires the version currently locked in victims' mix.lock - retiring needs the same owner permission as publishing. The retirement triggers Hex's cooldown bypass, so when a victim runs mix deps.update the resolver selects the brand-new malicious release despite it being younger than the configured cooldown window, defeating the age delay meant to give time to detect a hostile upload. No public exploit code was supplied.