CVE-2026-105668 in hex
Summary
by MITRE • 10/12/2026
Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner's account, to get a newly published release past the release-age cooldown.
The cooldown (cooldown config, HEX_COOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.
This issue affects hex: from 2.5.0 before 2.5.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified as a Protection Mechanism Failure within the hexpm Hex package manager represents a critical flaw in the integrity controls designed to prevent premature adoption of new software releases. The core mechanism at issue is the release-age cooldown, configured via HEX_COOLDOWN or organizational dependency policies, which serves to withhold versions younger than a specified age during dependency resolution processes. This feature is intended to provide stability and allow time for community vetting before packages are widely adopted in production environments. However, the implementation of this protection contains logical errors that can be exploited by malicious actors who have obtained ownership privileges over a package or compromised an owner account.
The technical flaw stems from how Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 handle cooldown bypasses when dealing with retired releases or those under security advisories. These functions are designed to lift the age restriction for a package locked in mix.lock, as well as all packages it depends on, thereby allowing developers using mix deps.update to migrate away from unsafe versions. The vulnerability arises because these bypass mechanisms check the cooldown status based solely on the package name rather than including additional context such as repository origin or specific version constraints that might differentiate legitimate updates from malicious ones. Consequently, an attacker who publishes a new release can subsequently retire the currently locked safe release. When this occurs, the system interprets the need to unlock the package and applies the cooldown bypass logic indiscriminately.
This sequence of actions allows any newly published release for that package name to be selected by mix deps.update regardless of its age, effectively circumventing the intended safety buffer. The impact is severe because it enables an attacker to force the adoption of a malicious version immediately after publication without waiting for the cooldown period to expire. Furthermore, due to the implementation detail where Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, this vulnerability extends beyond the specific repository instance. It affects packages with identical names in other repositories, potentially leading to widespread compromise across different ecosystems that share naming conventions or rely on similar dependency structures.
From a threat modeling perspective, this flaw aligns with CWE-693 Protection Mechanism Failure and falls under MITRE ATT&CK techniques related to Supply Chain Compromise, specifically leveraging legitimate administrative functions for malicious purposes. The attacker leverages the trust placed in package ownership permissions to execute a logic-based attack that subverts security controls designed to mitigate risk during dependency updates. This is particularly dangerous because it exploits standard operational workflows such as retiring old releases and updating dependencies, making detection difficult without deep inspection of repository activity logs.
Mitigation strategies must focus on immediate patching and enhanced monitoring. Organizations should upgrade the Hex package manager to version 2.5.2 or later, where this logical flaw has been addressed by refining how cooldown bypasses are evaluated to ensure they do not apply indiscriminately across all repositories sharing a name. Until patches are applied, administrators can enforce stricter dependency resolution policies that ignore automatic updates for packages with recent activity changes. Additionally, implementing rigorous monitoring of package retirement and publication events allows security teams to detect anomalous patterns indicative of this exploitation attempt. Restricting the ability to retire releases or requiring multi-factor authentication for such actions adds an additional layer of defense against account takeover scenarios that precede this specific vulnerability exploit.