Rebar3 constructs a dependency directory name directly from the app field supplied in a package release’s dependency list without validation. The description indicates that a malicious publisher could provide a value such as './../../../../target', which resolves to a location outside the project’s _build directory. When rebar3 fetches dependencies, it deletes that resolved directory with rm -rf and copies the fetched package files into it. The flaw allows unchecked deletion and placement of files, resulting in file system modification, potential data loss, and the injection of malicious artifacts. Based on the description, it is inferred that the attack vector exploits a classic path traversal weakness (CWE-22).

Erlang rebar3 versions from 3.7.0-rc1 up to but not including 3.27.2 are affected. Any user who invokes rebar3 to fetch dependencies from the Hex registry and uses an earlier version is at risk, regardless of the operating system. The vulnerability applies to all projects that rely on rebar3 for dependency resolution, including both direct and transitive dependencies.

The CVSS score of 7.5 indicates High severity. EPSS is not available and the flaw is not listed in CISA’s KEV catalog. Exploitation requires a malicious dependency that contains an unvalidated app field; this can arise from a compromised trusted publisher or via a newly published package by an attacker. Based on the description, it is inferred that once the malicious dependency is fetched, the attacker’s payload is executed automatically during get-deps, with no user interaction needed. This leads to unauthorized file deletion or placement, posing a significant confidentiality and integrity risk to the build environment.