EEF-CVE-2026-96612

Summary

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in hexpm hex allows a malicious package publisher to delete a directory outside the project's deps directory and extract package files into it when a developer fetches dependencies.

A package release's requirements carry an app label that names the dependency's OTP application. Hex takes this label from the repository's signed registry and uses it as the dependency's application name without validating it (Hex.RemoteConverger.deps/2, Hex.Mix.to_lock/1). Mix derives the dependency's checkout directory as deps/<app>, and Hex.SCM.update/1 runs File.rm_rf!/1 on that directory and unpacks the package into it. hex.pm only checks the label's length, so a publisher can set it to a value such as ../../target. When a project depends on such a release directly or transitively, mix deps.get or mix deps.update deletes the directory the label resolves to and writes the labelled package's files there. This happens before any dependency code is compiled.

This issue affects hex: from 0.6.0 before 2.5.2.

Details

1. hex.pm stores each requirement's app field with only a length check (255 codepoints) and copies it into the signed package registry resource when it differs from the dependency's package name.
2. Hex.RemoteConverger.deps/2 returns the dependency's children with String.to_atom/1 of that label as the application name, and Hex.Mix.to_lock/1 writes it as the mix.lock key.
3. Mix computes the dependency destination as Path.join(Mix.Project.deps_path(), Atom.to_string(app)) without validating the name.
4. Hex.SCM.update/1 calls File.rm_rf!(dest) and then Hex.Tar.unpack!(path, dest), so a label containing .. segments deletes and repopulates a directory outside deps.
5. Mix doesn't evaluate a Hex dependency's mix.exs during mix deps.get, so this is reachable before any package code runs.

Proof of concept

1. Publish package beta.
2. Publish package alpha with a requirement on beta whose app is ../../escape_marker.
3. In a project that depends on alpha, create ../escape_marker/canary.txt next to the project directory.
4. Run mix deps.get. Hex prints * Updating ../../escape_marker (Hex package), deletes canary.txt and writes beta's files into ../escape_marker.

Impact

A publisher of any package in a project's dependency tree can make mix deps.get delete a directory that the developer's account can write and that .. segments relative to deps reach, such as the project directory or its parent, and fill it with the labelled package's files. Writing attacker-chosen files into a directory whose contents are later run or loaded can lead to code execution without the developer compiling the dependency. Developers who fetch dependencies to review them before compiling, CI jobs and dependency update bots that only run mix deps.get or mix deps.update are affected.

Workarounds

Before running mix deps.get on a mix.lock from an untrusted change, check that every key in mix.lock is a plain application name without /, \ or ... There's no workaround for new dependency resolution with mix deps.update or mix deps.get without a lock entry.

Configurations

Affects projects whose dependency tree, directly or transitively, contains a package release whose registry metadata carries a crafted dependency app label, when dependencies are fetched with mix deps.get or mix deps.update. Packages on hex.pm are affected while hex.pm accepts such labels; packages on self-hosted repositories are affected when the repository operator signs such metadata.

Solutions

Upgrade Hex to 2.5.2 or later, for example with mix local.hex. Hex then skips package releases that give a dependency an application name other than a letter followed by letters, digits, _ and -, and warns about them. Resolution fails if no other release of the package fits the requirements.