Answer in brief
CVE-2026-103060 records a High severity (CVSS 7.5) vulnerability in Path traversal in rebar3 via unvalidated dependency app names. The current sources do not mark it as known exploited. The current feed maps erlang/erlang/rebar3 (generic), erlang/rebar3 (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps erlang/erlang/rebar3 (generic), erlang/rebar3 (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| erlang/erlang/rebar3generic | >=56b7d88975aa8da6446857cfd92de0825024bf63 <e35282b26e499b1d9e8f30bba9dccd71cd8b02ba | e35282b26e499b1d9e8f30bba9dccd71cd8b02ba |
| erlang/rebar3generic | >=3.7.0-rc1 <3.27.2 | 3.27.2 |
Published upstream
Oct 12, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 12, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 12, 2026
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.
Quoted source text, attributed separately from HOL analysis.