# RUSTSEC-2026-0412: Arbitrary code execution when rerunning tests from a portable recording


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 26 Oct 2026
- **Also known as:** GHSA-vc25-qg58-w57c

## What is RUSTSEC-2026-0412?

RUSTSEC-2026-0412 is a vulnerability in cargo-nextest, published on 26 Oct 2026. 

### Official description

## Summary

Nextest versions between 0.9.125 and 0.9.149 (inclusive) allow the `cargo nextest run --rerun` (or `-R`) command with a malicious [portable recording](https://nexte.st/docs/features/record-replay-rerun/portable-recordings/) to run arbitrary code during the build. The result is arbitrary code execution with the privileges of the user running `cargo nextest`.

This vulnerability requires that the experimental [run recording](https://nexte.st/docs/features/record-replay-rerun/) functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

## Details

Nextest's portable recordings contain [build scope arguments](https://nexte.st/docs/design/architecture/recording-runs/#build-scope-arguments). These arguments are deserialized verbatim from portable recordings, and are [not validated](https://github.com/nextest-rs/nextest/blob/70ba2393a05f29c54b72b4badb9635a86f162eb1/nextest-runner/src/record/format.rs#L421-L426). As a result, it is possible to construct an archive with a custom `--config` argument that causes Cargo to execute arbitrary code.

Nextest 0.9.150 records the build scope as structured data, and passes each value to Cargo joined to its flag (for example, `--package=<value>`), so a recording can no longer add other Cargo options.

## Impact

A malicious portable recording leads to arbitrary code execution as the user who runs `cargo nextest run --rerun`, during the build phase, before any test runs.

- The injected configuration takes effect during `cargo build`, so the payload is run even on a warm build cache, and even when no tests are ultimately executed. Inspecting the recorded tests (with e.g. `cargo nextest replay`) before running them does not help, since the code has already run by the time the tests would start.
- Arbitrary code execution happens as the invoking user, without a prompt or trust warning. The only signal is a `rerun: inheriting build scope…` line. On CI, this includes access to whatever secrets are accessible to the job, including repository tokens and deployment credentials.
- A malicious payload can invoke the real compiler afterwards, so the build and tests complete normally. The recording is otherwise a valid, ordinary recording.
- The full Cargo `--config` surface is exposed. This includes `build.rustc-wrapper`, `build.rustc`, `target.*.linker`, `target.*.runner`, `env.*`, and `patch.*` and `source.*.replace-with` (redirecting dependencies to an attacker-controlled repository or registry).
- The delivery mechanism matches the feature's intended use, since portable recordings are designed to be shared across machines. For example, an attacker could pose as a user asking a maintainer for help triaging their flaky test report. Because `--rerun` also accepts process substitution, `cargo nextest run --rerun <(curl …)` would fetch the recording directly from a URL.

Exploitation requires convincing the victim to run `cargo nextest run --rerun` against an attacker-supplied portable recording. The rerun feature is experimental and must be enabled, via e.g. `NEXTEST_EXPERIMENTAL_RECORD=1`.

## Remediations

- Upgrade cargo-nextest to version 0.9.150 or above.
- In your repositories, set the [minimum required version](https://nexte.st/docs/configuration/minimum-versions/) to 0.9.150. In `.config/nextest.toml`:
  ```toml
  nextest-version = "0.9.150"
  ```
  This way, anyone who interacts with your repository will be notified to upgrade their version of nextest.
- If you are using an affected version, do not enable the experimental run recording feature.

## Credit

Reported by [inanna-malick](https://github.com/inanna-malick).

## Which versions are affected by RUSTSEC-2026-0412?

1 open source package ship an affected version, including cargo-nextest.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `cargo-nextest` | crates.io | From 0.9.125 | 0.9.150 |

## How do I fix RUSTSEC-2026-0412?

Upgrade cargo-nextest to 0.9.150 or later.

## Is RUSTSEC-2026-0412 being exploited?

There is no known exploitation of RUSTSEC-2026-0412 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for RUSTSEC-2026-0412 and fix it if it is affected.

What it is: RUSTSEC-2026-0412 is a vulnerability in cargo-nextest, published on 26 Oct 2026. 
Exploitation: There is no known exploitation of RUSTSEC-2026-0412 in the wild and no public exploit code.

Affected packages and fixed versions:
- cargo-nextest (crates.io): affected from 0.9.125; fixed in 0.9.150

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/RUSTSEC-2026-0412/ (Markdown: https://insights.sbomify.com/RUSTSEC-2026-0412/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/RUSTSEC-2026-0412

---
From sbomify Insights: https://insights.sbomify.com/RUSTSEC-2026-0412/
Summaries are generated and may contain mistakes; the official description above is the record.