CVE-2026-103060: Path traversal in rebar3 via unvalidated dependency app names
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/rebar3to a version that resolves this vulnerability.Fixed in 3.27.2
Event History
Frequently Asked Questions
Who is exposed to this issue?
Projects using affected rebar3 versions are exposed when they fetch a direct or transitive dependency whose Hex release contains a malicious app field. Exploitation requires a developer to run get-deps for a project that resolves that release.
What can an attacker do, and what access do they need?
A malicious package publisher can set the dependency app field to a path such as ../../../../target. When dependencies are fetched, rebar3 can delete the resolved target directory outside _build and extract the package files into that location; no attacker authentication is required, but developer interaction is required.
Does exploitation require dependency code to be compiled or a rebar.config.script to run?
No. The deletion and extraction occur during get-deps before the dependency's rebar.config.script is evaluated, and get-deps compiles nothing.
Which rebar3 versions are affected?
The issue affects rebar3 versions from 3.7.0-rc1 before 3.27.2.
How can teams determine whether a project may have been affected?
Review direct and transitive Hex dependencies fetched by affected rebar3 versions for release dependency app fields containing path traversal values rather than directory-safe application names. Also investigate unexpected deletion or replacement of directories outside the project's _build directory after running get-deps.