Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project's build directory and extract package files into it when a developer fetches dependencies.

A package release's dependencies in a Hex registry carry an app field that names the dependency's OTP application. rebar3 uses this field as the dependency's name without validating it (rebarpackages:parsedeps/1) and builds the dependency's directory from that name (rebarapputils:deptoapp/7). rebarfetch:downloadsourceonline/2 deletes that directory with rm -rf and moves the fetched package into it. hex.pm didn't restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target. When a project depends on such a release directly or transitively, rebar3 get-deps deletes the directory the name resolves to and writes the dependency's files there. This happens before the dependency's own rebar.config.script is evaluated, and get-deps compiles nothing.

This issue affects rebar3: from 3.7.0-rc1 before 3.27.2.

Impact

The Hex client (hexcore) deserializes Erlang terms received from the Hex API using binarytoterm/1 without sufficient restrictions.

If an attacker can control the HTTP response body returned by the Hex API, this allows denial-of-service attacks such as atom table exhaustion, leading to a VM crash. No released versions are known to allow remote code execution.

Patches

https://github.com/hexpm/hexcore/commit/cdf726095bca85ad2549d146df1e831ae93c2b13 https://github.com/hexpm/hex/commit/636739f3322514e9303ca335fb630696fcbb3c95 https://github.com/erlang/rebar3/commit/1d4478f527e373de0b225951e53115450e0d9b9d

Workarounds

Ensure that the Hex API URL (HEXAPIURL) points only to trusted endpoints. There is no client-side workaround that fully mitigates this issue without applying the patch.

Resources

hexcore Module: https://github.com/hexpm/hexcore/blob/main/src/hexapi.erl Hex Vendored Module: https://github.com/hexpm/hex/blob/main/src/mixhexapi.erl Rebar3 Vendored Module: https://github.com/erlang/rebar3/blob/main/apps/rebar/src/vendored/r3hexapi.erl hexcore Patch: https://github.com/hexpm/hexcore/commit/cdf726095bca85ad2549d146df1e831ae93c2b13 Hex Vendored Patch: https://github.com/hexpm/hex/commit/636739f3322514e9303ca335fb630696fcbb3c95 Rebar3 Vendored Patch: https://github.com/erlang/rebar3/commit/1d4478f527e373de0b225951e53115450e0d9b9d

Erlang/OTP Rebar3 version 3.7.0 through 3.7.5 contains a Signing oracle vulnerability in Package registry verification that can result in Package modifications not detected, allowing code execution. This attack appears to be exploitable via Victim fetches packages from malicious/compromised mirror. This vulnerability appears to have been fixed in 3.8.0.

Rebar3 versions 3.0.0-beta.3 to 3.13.2 are vulnerable to OS command injection via URL parameter of dependency specification.