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 (rebar_packages:parse_deps/1) and builds the dependency's directory from that name (rebar_app_utils:dep_to_app/7). rebar_fetch:download_source_online/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.
No advisories yet.
Solution
Upgrade rebar3 to 3.27.2 or later, for example with rebar3 local upgrade. rebar3 then fails with an error when a dependency's name, including the app name a package release gives a dependency, isn't a letter followed by letters, digits, _ and -.
Workaround
No workaround given by the vendor.
Mon, 12 Oct 2026 16:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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 (rebar_packages:parse_deps/1) and builds the dependency's directory from that name (rebar_app_utils:dep_to_app/7). rebar_fetch:download_source_online/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. | |
| Title | Path traversal in rebar3 via unvalidated dependency app names | |
| First Time appeared |
Erlang
Erlang rebar3 |
|
| Weaknesses | CWE-22 | |
| CPEs | cpe:2.3:a:erlang:rebar3:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Erlang
Erlang rebar3 |
|
| References |
|
|
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-10-12T15:43:57.636Z
Reserved: 2026-10-06T08:45:01.521Z
Link: CVE-2026-103060
No data.
Status : Received
Published: 2026-10-12T16:17:00.873
Modified: 2026-10-12T16:17:00.873
Link: CVE-2026-103060
No data.
OpenCVE Enrichment
Updated: 2026-10-12T18:30:16Z