EEF-CVE-2026-97209: Insecure temporary file in mix deps.partition lets a local user execute code in another user's dependency build

Published Oct 30, 2026
·
Updated

Summary

Insecure Temporary File vulnerability in Mix deps.partition in Elixir allows a local user to execute code as another user via a swapped partition config file. Partitioned dependency compilation passes the project configuration to each partition VM through a file in a fixed-name directory under the shared system temporary directory, and the partition trusts what it reads back. Another local user on the same host can exploit this during a mix deps.compile run that uses partitioned compilation.

Mix.Tasks.Deps.Partition.server/4 in lib/mix/lib/mix/tasks/deps.partition.ex creates the directory with File.mkdirp/1, which accepts an existing directory without checking its owner, so a user who created it first can replace the file before client/0 reads it.

This issue affects mix: from 1.20.0-rc.4 before 1.20.5.

Details

1. Payload written to a shared location

Mix.Tasks.Deps.Partition.server/4 in lib/mix/lib/mix/tasks/deps.partition.ex encodes Mix.ProjectStack.peek() with :erlang.termtobinary/1 and Base64, calls File.mkdirp/1 on Path.join(System.tmpdir(), "mixdepspartition"), and writes the payload to a file with a random name inside it. The directory name is fixed, carries no user id, and File.mkdirp/1 succeeds on a directory that already exists, whoever owns it. The file is created with the default mode, so it is readable by other users in a shared temporary directory.

2. Partition VMs trust the file

Each partition is a fresh elixir VM started with --config-file <path>. Mix.Tasks.Deps.Partition.client/0 reads the file with File.read!/1, decodes it with :erlang.binarytoterm/1, and pushes the decoded entry (project name, config and mix.exs path) with Mix.ProjectStack.push/3. Nothing verifies that the file still holds what the parent wrote.

3. Attacker control

A local user who created mixdepspartition before the victim's build owns it and may replace or rewrite any file inside, so they swap the payload between the parent's write and the client's read. The client then compiles the attacker's deps list, and a dependency's compile: option is a shell command Mix executes in the victim's build. On the development branch the payload also carries codepath and compileroptions, which the client applies with :code.setpath/1 and Code.compileroptions/1, so there the attacker also controls the client VM's code path.

Proof of concept

1. On a multi-user Linux host where System.tmpdir() resolves to /tmp, the attacker creates /tmp/mixdepspartition as their own directory and watches it for new files. 2. The victim runs mix deps.compile (directly, or through mix compile or mix test) with MIXOSDEPSCOMPILEPARTITIONCOUNT=2 on a project with at least two non-local dependencies. File.mkdirp/1 succeeds on the existing directory and the config file is written into it. 3. Before the partition VMs boot and read the file, the attacker decodes it, adds a compile: shell command to every dependency in config[:deps], re-encodes it and writes it back. 4. Each partition decodes the attacker's term and deps.compile runs the injected command as the victim user.

Impact

A local user on a shared host who creates the partition directory before the victim's build replaces the serialized configuration and runs arbitrary shell commands as the developer or CI user whose mix deps.compile uses partitioned compilation.

Even without pre-creating the directory, the world-readable partition file discloses the project configuration, including Mix.install compile-time config, to other local users while the build runs.

Workarounds

On a multi-user host, set TMPDIR to a private per-user directory with mode 0700 before running Mix, so that System.tmpdir/0 resolves to a location other users cannot pre-create or read. Alternatively, keep partitioned compilation disabled by leaving MIXOSDEPSCOMPILEPARTITIONCOUNT unset or at 1, which keeps the configuration inside the parent process.

Configurations

The attack requires partitioned dependency compilation, which is off by default and enabled by setting MIXOSDEPSCOMPILEPARTITIONCOUNT to a value greater than one, a mix deps.compile run that compiles at least two non-local dependencies, and a system temporary directory shared with other local users, which is the default on Linux when TMPDIR is unset. Platforms with per-user temporary directories, such as macOS and Windows by default, are not affected unless TMPDIR points at a shared location.

Other sources

Insecure Temporary File vulnerability in Mix deps.partition in Elixir allows a local user to execute code as another user via a swapped partition config file. Partitioned dependency compilation passes the project configuration to each partition VM through a file in a fixed-name directory under the shared system temporary directory, and the partition trusts what it reads back. Another local user on the same host can exploit this during a mix deps.compile run that uses partitioned compilation.

Mix.Tasks.Deps.Partition.server/4 in lib/mix/lib/mix/tasks/deps.partition.ex creates the directory with File.mkdirp/1, which accepts an existing directory without checking its owner, so a user who created it first can replace the file before client/0 reads it.

This issue affects mix: from 1.20.0-rc.4 before 1.20.5.

— OSV

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Mix to a version that resolves this vulnerability.

    Fixed in 1.20.5
  2. Configuration

    Keep partitioned dependency compilation disabled by leaving MIX_OS_DEPS_COMPILE_PARTITION_COUNT unset or setting it to 1.

    Mix dependency compilation MIX_OS_DEPS_COMPILE_PARTITION_COUNT = unset or 1
  3. Configuration

    Set TMPDIR to a private per-user directory with mode 0700 before running Mix, so other local users cannot pre-create or read the partition directory and files.

    Mix temporary-file location TMPDIR = private per-user directory with mode 0700

Event History

Oct 30, 2026
CVE Published
via OSV·08:59 AM
Data Sourced
via OSV·08:59 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which installations are affected?

Mix versions from 1.20.0-rc.4 before 1.20.5 are affected. Exposure requires running mix deps.compile with partitioned dependency compilation.

2

What access does an attacker need?

The attacker needs to be another local user on the same host. They must be able to create the shared temporary directory first and replace the partition configuration file during the dependency compilation run.

3

How can I determine whether a build may have been exposed?

Check whether the system ran an affected Mix version and used partitioned dependency compilation. A potentially exposed run is one where another local user could have pre-created or modified the mix_deps_partition directory under the shared system temporary directory during compilation.

4

What version should be used to remediate the issue?

Upgrade Mix to version 1.20.5 or later. The affected range ends before 1.20.5.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203