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.
Analysis and contextual insights are available on OpenCVE Cloud.
Vendor 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 -.
Tracking
Sign in to view the affected projects.
No advisories yet.
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
|
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
No data.