Path traversal in rebar3 via unvalidated dependency app names
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| erlang | rebar3 | unaffected |
|
||||||
| erlang | rebar3 | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Erlang | Rebar3 |
|
||||||||||||
| Erlang | Rebar3 |
|
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 -.
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.451% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| 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
|