Hex CVE-2026-96612

Requires that the victim's Mix project depend - directly or transitively - on a Hex package release that the attacker controls or has compromised, and whose requirement entry carries a malicious OTP application label (e.g., '../../target'); hex.pm only length-checks this label, so traversal sequences pass. A developer must then actively run mix deps.get or mix deps.update, which triggers File.rm_rf! on the resolved out-of-tree path and extraction of the package there before any dependency code compiles. Affects hex versions from 0.6.0 up to (not including) 2.5.2. Limiting factors: the attacker must get a malicious release into a registry/repository the victim consumes AND the victim must choose to depend on it, and exploitation only fires on explicit developer dependency-fetch actions (UI required) - there is no server-side or unauthenticated-victim trigger. No authentication is required on the victim side; impact lands on the developer/CI host performing the fetch.

This is a supply-chain path traversal in Hex, the package manager for the Elixir/Erlang (Mix) ecosystem, rated CVSS 7.5 under the vendor's 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H). The network attack vector is real in the sense that the malicious payload travels through the public/private Hex registry, but exploitation is gated by two significant conditions the raw score partially captures: AT:P (the victim must depend, directly or transitively, on a release the attacker controls) and UI:A (a developer must actively run mix deps.get / mix deps.update). It is therefore not a drive-by remote exploit against a listening service - it is a build-time/developer-workstation attack requiring victim action and a dependency relationship. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation status is 'no public exploit identified at time of analysis'; absence of these signals is not evidence of safety, but it argues against widespread opportunistic exploitation and toward targeted, trust-abuse scenarios. The vendor's VC:H (confidentiality high) rating is debatable - the described primitive is arbitrary directory deletion plus arbitrary file extraction (integrity/availability), not information disclosure - so this signal should be verified rather than taken as confirmed. Overall this is a genuine, patch-worthy supply-chain integrity flaw for any Elixir shop, but its real-world priority is moderated by the dependency and user-interaction prerequisites rather than being an internet-facing critical.

A malicious or compromised package publisher pushes a Hex release whose dependency requirement carries a crafted OTP application label such as '../../target'. When a developer whose project depends on that release (directly or transitively) runs mix deps.get, Hex trusts the registry-supplied label, resolves the checkout path to deps/../../target, runs File.rm_rf! on it, and unpacks the attacker's package files into that location before any code is compiled. No public POC was provided, but the primitive enables deletion of arbitrary directories and planting of attacker-controlled files on the developer's machine.