GHSA-vc25-qg58-w57c json
Arbitrary code execution when rerunning tests from a portable recording
published 18d ago modified 17d ago also RUSTSEC-2026-0412
- cvss
- 7.8
- version 3.1, OSV
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
## 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).
Patch / fix
- crates.io cargo-nextest 0.9.150
Is GHSA-vc25-qg58-w57c in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| OSV | 3.1 | 7.8 | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | cargo-nextest | >=0.9.125, <0.9.150 |
0.9.150 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.