https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 13 Oct 2026 04:23:48 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-103060 <p>Improper Limitation of a Pathname to a Restricted Directory (&#39;Path Traversal&#39;) vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project&#39;s _build directory and extract package files into it when a developer fetches dependencies.</p> <p>A package release&#39;s dependencies in a Hex registry carry an app field that names the dependency&#39;s OTP application. rebar3 uses this field as the dependency&#39;s name without validating it (rebar_packages:parse_deps/1) and builds the dependency&#39;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&#39;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&#39;s files there. This happens before the dependency&#39;s own rebar.config.script is evaluated, and get-deps compiles nothing.</p> <p>This issue affects rebar3: from 3.7.0-rc1 before 3.27.2.</p> <p>Improper Limitation of a Pathname to a Restricted Directory (&#39;Path Traversal&#39;) vulnerability in erlang rebar3 allows a malicious package publisher to delete a directory outside the project&#39;s _build directory and extract package files into it when a developer fetches dependencies.</p> <p>A package release&#39;s dependencies in a Hex registry carry an app field that names the dependency&#39;s OTP application. rebar3 uses this field as the dependency&#39;s name without validating it (rebar_packages:parse_deps/1) and builds the dependency&#39;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&#39;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&#39;s files there. This happens before the dependency&#39;s own rebar.config.script is evaluated, and get-deps compiles nothing.</p> <p>This issue affects rebar3: from 3.7.0-rc1 before 3.27.2.</p> https://db.gcve.eu/vuln/fkie_cve-2026-103060