CVE-2026-103060

Executive Summary

CVE-2026-103060 is a path traversal vulnerability (CWE-22) in rebar3, the Erlang build tool and package manager. A malicious package publisher can craft a Hex registry release whose dependency app field contains a traversal value such as ../../../../target, causing rebar3 to resolve the dependency's directory outside the project's _build directory and delete it via rm -rf before extracting package files into that location. Any developer or CI system that fetches dependencies with rebar3 get-deps from an affected rebar3 version (3.7.0-rc1 through before 3.27.2) is at risk of arbitrary directory deletion and file write outside the intended build path.

Technical Analysis

The vulnerability resides in the way rebar3 ingests dependency metadata from a Hex registry. A package release's dependencies carry an app field that names the dependency's OTP application. rebar3 consumes this field as the dependency's name without validation in rebar_packages:parse_deps/1, and then constructs the dependency's on-disk directory from that name in rebar_app_utils:dep_to_app/7. The resulting path is not constrained to the project's _build directory.

When dependencies are fetched, rebar_fetch:download_source_online/2 deletes the computed directory using rm -rf and then moves the fetched package into it. Because the directory is derived from an unvalidated name, a traversal sequence embedded in the app field causes both the delete and the subsequent file extraction to operate outside the intended restricted directory. The NVD description explicitly states that hex.pm did not restrict the app field to a directory name before 2026-10-12, which is the window during which a publisher could set the field to a traversal value.

Two characteristics amplify the risk. First, the behavior is reachable through transitive dependencies, meaning a project does not need to depend on the malicious release directly; any dependency chain that pulls the crafted release into the dependency graph triggers the same code path. Second, the destructive and write operations occur before the dependency's own rebar.config.script is evaluated, and get-deps compiles nothing. This means the traversal and its impact occur during the dependency-resolution and fetch phase, independent of any build-time hooks or scripts that defenders might otherwise scrutinize. The attack surface is therefore the dependency resolution pipeline itself, exercised during routine developer workflows and automated CI dependency installs.

The root cause class is improper limitation of a pathname to a restricted directory: a package-controlled identifier is used to build a filesystem path without normalization or containment checks, allowing an attacker-supplied value to escape the intended _build root. The affected range is rebar3 from 3.7.0-rc1 before 3.27.2.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the mechanics described in the NVD entry.

1. Reconnaissance and target identification. The attacker identifies an ecosystem where rebar3 is widely used and where dependency resolution is performed automatically, for example developer workstations and CI/CD runners that execute rebar3 get-deps against Hex. The attacker registers or controls a Hex package publisher account and prepares a release intended to be consumed either directly by a target project or transitively through a popular dependency.

2. Triggering the flaw class. The attacker publishes a Hex release whose dependency entry contains an app field set to a traversal value, such as ../../../../target, as described in the NVD entry. Because hex.pm did not restrict this field to a directory name before 2026-10-12, the malicious value is accepted and stored in the registry metadata.

3. Payload and execution method. When a consuming project depends on the crafted release, rebar3 parses the dependency metadata via rebar_packages:parse_deps/1 and uses the unvalidated name to build the directory path in rebar_app_utils:dep_to_app/7. During rebar_fetch:download_source_online/2, rebar3 executes rm -rf on the resolved directory — which now points outside _build — and then moves the fetched package files into that path. No code execution is required for the destructive effect; the get-deps operation itself performs the deletion and write.

4. Post-exploitation impact. The immediate result is deletion of a directory outside the project's _build directory via the rm -rf operation, followed by writing attacker-controlled package files into the resolved location. Depending on where the traversal resolves and the privileges of the user or runner executing rebar3, this can destroy unrelated data on the filesystem, overwrite files in the write target, and seed an alternate directory with dependency files. The description notes this occurs before the dependency's own rebar.config.script is evaluated and that get-deps compiles nothing, so the impact is realized during dependency fetch rather than at compile time.

Impact Assessment

The vulnerability class is path traversal with destructive and write primitives. Its confidentiality impact is limited, but integrity and availability impacts are high: an attacker-controlled path can cause deletion of an arbitrary directory reachable by the process and can place files at a location of the attacker's choosing within that path constraint. The blast radius includes not only the project that directly depends on the malicious release but also, per the description, any project that depends on it transitively.

Affected systems are environments that resolve Hex dependencies with rebar3 versions from 3.7.0-rc1 through before 3.27.2, including developer machines and build infrastructure. Because the trigger occurs during routine dependency fetching, a single compromised or malicious package release can affect many downstream projects across the ecosystem. CI/CD runners are a particularly sensitive target: filesystem write access on a runner can disrupt subsequent build steps, and deletion of directories outside _build can break tool setups or shared caches.

The CVSS base score is not provided in the supplied data (N/A), and the EPSS score is not yet available from FIRST.org. A CVSS vector consistent with the described mechanics is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H, reflecting network-sourced attack input, low complexity, no privileges, user interaction required to fetch the malicious dependency, and high integrity and availability impact. This vector is an analytical assessment, not a vendor-published score. CVE-2026-103060 is not listed in CISA KEV, and no public exploit code or Nuclei template was identified.

Detection Guidance

Sigma Rule

title: Potential rebar3 Path Traversal via Malicious Dependency App Field
id: 7c3c9f2a-4e1b-4d8e-9a2f-103060aaaa
status: experimental
description: Detects rebar3 fetching operations where the dependency app name or build path appears to contain directory traversal, consistent with CVE-2026-103060.
author: valtersit.com
date: 2026-01-01
logsource:
  product: linux
  service: process_creation
detection:
  selection_proc:
    Image|endswith:
      - '/rebar3'
      - '/escript'
  selection_args:
    CommandLine|contains:
      - 'get-deps'
      - 'rebar3 fetch'
  selection_traversal:
    CommandLine|contains:
      - '../../..'
      - '..\\..\\'
  condition: selection_proc and (selection_args or selection_traversal)
falsepositives:
  - Legitimate projects that intentionally reference parent directories in build configuration
level: medium
tags:
  - attack.t1195.002
  - cve.2026-103060

YARA Rule

rule CVE_2026_103060_Rebar3_App_Traversal
{
    meta:
        description = "Detects rebar3 dependency metadata containing directory traversal in the app field, consistent with CVE-2026-103060"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103060"
        cve = "CVE-2026-103060"

    strings:
        $app1 = "app" ascii
        $trav1 = "../../../" ascii
        $trav2 = "..\\..\\.." ascii
        $build = "_build" ascii

    condition:
        uint16(0) != 0x5A4D and
        $app1 and
        any of ($trav*) and
        $build
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103060 rebar3 Path Traversal Dependency App Field"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"hex.pm"; content:"/packages/"; pcre:"/(\.\.\/){2,}/U"; reference:cve,2026-103060; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-103060; classtype:attempted-user; sid:2026103060; rev:1;)

Elastic Detection

process where event.type == "start" and
  (process.name == "rebar3" or process.name == "escript") and
  process.command_line : ("*get-deps*", "*rebar3 fetch*") and
  process.command_line : ("*../../*", "*..\\..\\*")

Splunk SPL Query

index=* (process_name=rebar3 OR process_name=escript) (CommandLine="*get-deps*" OR CommandLine="*fetch*")
| regex CommandLine="(\.\./){2,}|(\.\.\\\\){2,}"
| stats count min(_time) as firstTime max(_time) as lastTime by host, user, process_name, CommandLine
| convert ctime(firstTime) ctime(lastTime)

Wazuh OSSEC Rule

<group name="rebar3,cve-2026-103060,">
  <rule id="103060" level="10">
    <if_sid>5925</if_sid>
    <field name="command">rebar3|escript</field>
    <field name="command">get-deps|fetch</field>
    <regex>(\.\./){2,}|(\.\.\\){2,}</regex>
    <description>CVE-2026-103060: Possible rebar3 dependency path traversal during get-deps/fetch</description>
    <mitre>
      <id>T1195.002</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations. Reduce exposure during dependency resolution by treating package metadata as untrusted input. Where operationally feasible, run rebar3 get-deps in an isolated, disposable environment with a restricted filesystem view and least-privilege credentials, so that any traversal-driven rm -rf and file write are contained. Restrict the running user's permissions so it cannot delete or overwrite files outside the workspace. Pin dependencies to known-good releases and review dependency graphs for unexpected transitive entries. Consider deferring automatic dependency refresh until the registry metadata field is enforced, given the reported window during which hex.pm did not restrict the app field before 2026-10-12.

2. Patch and upgrade steps. No patch evidence is available from any tracked source, and no vendor fix or workaround is documented in the supplied data. The published affected range is rebar3 from 3.7.0-rc1 before 3.27.2; upgrading to 3.27.2 or later is the indicated version boundary for remediation, subject to confirmation from the project maintainers. Monitor the rebar3 and Hex project advisories for an authoritative fix, and validate directory-containment behavior after upgrading.

3. Long-term hardening. Enforce that package metadata identifiers used to construct filesystem paths are limited to a sanitized directory name, with normalization and containment checks that reject traversal sequences. Treat all registry-supplied fields as untrusted and validate them at ingestion. Adopt CI/CD practices that prevent build jobs from holding destructive privileges over paths outside the workspace, and sustain monitoring for anomalous directory deletion followed by unexpected file creation during dependency resolution.

References

• NVD — CVE-2026-103060: https://nvd.nist.gov/vuln/detail/CVE-2026-103060
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html
• rebar3 project (Erlang build tool): https://rebar3.org/
• Hex package registry: https://hex.pm/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-103060 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, or Nuclei template was identified for CVE-2026-103060 at the time of writing, and the EPSS score is not yet available from FIRST.org. No threat actor campaigns or exploit-in-the-wild evidence were identified in the supplied data.