Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in erlang rebar3 allows a malicious package …
CVE-2026-103060 · published 12 Oct 2026
How serious is it
- Severity: high, CVSS score 7.5 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-103060?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
- erlang rebar3: 56b7d88975aa8da6446857cfd92de0825024bf63 to < e35282b26e499b1d9e8f30bba9dccd71cd8b02ba
How to check
- Find out whether you run the affected product and which version, then compare it with the versions above.
How to fix
Copies a prompt for Claude Code, Cursor or Codex that asks it to check whether you run this product.
- Apply the vendor's update or mitigation from the references below. If there is none yet, limit exposure of the affected service until there is.
- If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
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.
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- cna.erlef.org/cves/CVE-2026-103060.html
- github.com/erlang/rebar3/commit/56b7d88975aa8da6446857cfd92de0825024bf63
- github.com/erlang/rebar3/commit/e35282b26e499b1d9e8f30bba9dccd71cd8b02ba
- github.com/erlang/rebar3/security/advisories/GHSA-6ggr-r7mh-2mv8
- osv.dev/vulnerability/EEF-CVE-2026-103060
Merged from NVD. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON