rebar3 EUVD-2026-97510

Requires a malicious or compromised Hex package release whose dependency 'app' field contains path-traversal sequences (e.g. ../../../../target), AND a victim project that depends on that release directly or transitively, AND a developer/CI action that fetches dependencies (rebar3 get-deps). Affects only rebar3 3.7.0-rc1 through 3.27.1. Limiting factors: exploitation happens before the dependency's rebar.config.script runs and get-deps compiles nothing, so this is file deletion/overwrite rather than immediate code execution; the public hexpm registry restricted the field as of 2026-10-12, so the primary residual exposure is private/self-hosted Hex registries lacking that restriction and any already-published malicious releases.

This is a supply-chain path traversal (CWE-22) in rebar3, the de facto build tool for the Erlang/OTP ecosystem. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A, score 7.5) correctly captures the key tensions: the attack reaches the victim over the network via the Hex registry (AV:N) and needs no privileges on the victim's machine (PR:N), BUT it requires two conditions outside the attacker's direct control - an attack requirement (AT:P) that the victim actually depend, directly or transitively, on the malicious release, and active user interaction (UI:A) where a developer runs dependency fetching (rebar3 get-deps). These prerequisites meaningfully lower real-world likelihood versus a drive-by RCE. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no evidence of active or at-scale exploitation - treat the risk as credible supply-chain abuse potential rather than an imminent widespread threat. A critical mitigating signal: the description states hex.pm server-side restricted the vulnerable 'app' field as of 2026-10-12 (today), so the public hexpm registry no longer accepts malicious values; residual risk concentrates on private/self-hosted Hex registries and any already-published malicious releases. Note a signal to verify: the input 4.0 vector marks confidentiality impact VC:H, but the described behavior is directory deletion (rm -rf) and arbitrary file write, not disclosure - the realistic impact is integrity/availability, which lowers the effective confidentiality component.

A malicious actor publishes a Hex package whose release metadata sets the OTP application 'app' field to a path-traversal value such as '../../../../target'. A developer adds that package (or unknowingly pulls it transitively) and runs rebar3 get-deps; rebar3 resolves the dependency directory from the unvalidated name, deletes the attacker-chosen directory with rm -rf, and extracts the package contents there - enabling destruction of arbitrary developer/CI directories and planting of attacker files outside the _build sandbox. No public exploit code was identified in the provided data, though the mechanism is fully described in the advisory and patch commit.