cargo-nextest

Version	Released
`0.9.150` patch	Oct 26, 2026
`0.9.149` patch 1 CVE	Oct 20, 2026
`0.9.148` patch 1 CVE	Oct 08, 2026
`0.9.146` patch 1 CVE	Sep 21, 2026
`0.9.145` patch 1 CVE	Sep 16, 2026
`0.9.144` patch 1 CVE	Sep 10, 2026
`0.9.143` patch 1 CVE	Aug 04, 2026
`0.9.140` patch 1 CVE	Jul 05, 2026
`0.9.140-b.2` pre 1 CVE	Jul 05, 2026
`0.9.140-b.1` pre 1 CVE	Jul 05, 2026
`0.9.138` patch 1 CVE	Jun 21, 2026
`0.9.137` patch 1 CVE	May 26, 2026
`0.9.136` patch 1 CVE	May 17, 2026
`0.9.135` patch 1 CVE	May 14, 2026
`0.9.133` patch 1 CVE	Apr 14, 2026
`0.9.132` patch 1 CVE	Mar 20, 2026
`0.9.132-rc.3` pre 1 CVE	Mar 20, 2026
`0.9.131` patch 1 CVE	Mar 18, 2026
`0.9.131-rc.3` pre 1 CVE	Mar 17, 2026
`0.9.131-rc.2` pre 1 CVE	Mar 17, 2026
`0.9.130` patch 1 CVE	Mar 10, 2026
`0.9.129` patch 1 CVE	Feb 22, 2026
`0.9.128` patch 1 CVE	Feb 19, 2026
`0.9.127` patch 1 CVE	Feb 13, 2026
`0.9.126` patch 1 CVE	Feb 04, 2026
`0.9.125` patch 1 CVE	Feb 04, 2026
`0.9.124` patch	Jan 25, 2026
`0.9.123` patch	Jan 23, 2026
`0.9.123-b.4` pre	Jan 23, 2026
`0.9.123-b.3` pre	Jan 21, 2026
`0.9.123-b.2` pre	Jan 19, 2026
`0.9.123-b.1` pre	Jan 18, 2026
`0.9.122` patch	Jan 14, 2026
`0.9.121` patch	Jan 12, 2026
`0.9.120` patch	Jan 08, 2026
`0.9.119-b.2` pre	Jan 05, 2026
`0.9.119-b.1` pre	Jan 05, 2026
`0.9.118` patch	Jan 04, 2026
`0.9.117` patch	Jan 02, 2026
`0.9.116` patch	Dec 27, 2025
`0.9.115` patch	Dec 15, 2025
`0.9.114` patch	Nov 19, 2025
`0.9.113` patch	Nov 16, 2025
`0.9.113-b.1` pre	Nov 16, 2025
`0.9.111` patch	Nov 04, 2025
`0.9.110` patch	Oct 31, 2025
`0.9.109` patch	Oct 30, 2025
`0.9.108` patch	Oct 21, 2025
`0.9.108-b.1` pre	Oct 21, 2025
`0.9.106` patch	Oct 13, 2025

0.9.150 patch

Oct 26, 2026

0.9.149 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Oct 20, 2026

0.9.148 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Oct 08, 2026

0.9.146 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Sep 21, 2026

0.9.145 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Sep 16, 2026

0.9.144 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Sep 10, 2026

0.9.143 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Aug 04, 2026

0.9.140 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Jul 05, 2026

0.9.140-b.2 pre

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Jul 05, 2026

0.9.140-b.1 pre

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Jul 05, 2026

0.9.138 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Jun 21, 2026

0.9.137 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

May 26, 2026

0.9.136 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

May 17, 2026

0.9.135 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

May 14, 2026

0.9.133 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Apr 14, 2026

0.9.132 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 20, 2026

0.9.132-rc.3 pre

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 20, 2026

0.9.131 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 18, 2026

0.9.131-rc.3 pre

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 17, 2026

0.9.131-rc.2 pre

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 17, 2026

0.9.130 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Mar 10, 2026

0.9.129 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Feb 22, 2026

0.9.128 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Feb 19, 2026

0.9.127 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Feb 13, 2026

0.9.126 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Feb 04, 2026

0.9.125 patch

1 CVE

RUSTSEC-2026-0412 GHSA-vc25-qg58-w57c Oct 26, 2026

Arbitrary code execution when rerunning tests from a portable recording

7.8 / 10

High

Local Low None Required Unchanged High High High

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 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 functionality is enabled. An attacker can plausibly trick a victim into enabling this feature.

Details

Nextest's portable recordings contain build scope arguments. These arguments are deserialized verbatim from portable recordings, and are not validated. 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 to 0.9.150. In .config/nextest.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.

Fixed in


          0.9.150

References

Updated Oct 27, 2026 · Source: OSV.dev

Feb 04, 2026

0.9.124 patch

Jan 25, 2026

0.9.123 patch

Jan 23, 2026

0.9.123-b.4 pre

Jan 23, 2026

0.9.123-b.3 pre

Jan 21, 2026

0.9.123-b.2 pre

Jan 19, 2026

0.9.123-b.1 pre

Jan 18, 2026

0.9.122 patch

Jan 14, 2026

0.9.121 patch

Jan 12, 2026

0.9.120 patch

Jan 08, 2026

0.9.119-b.2 pre

Jan 05, 2026

0.9.119-b.1 pre

Jan 05, 2026

0.9.118 patch

Jan 04, 2026

0.9.117 patch

Jan 02, 2026

0.9.116 patch

Dec 27, 2025

0.9.115 patch

Dec 15, 2025

0.9.114 patch

Nov 19, 2025

0.9.113 patch

Nov 16, 2025

0.9.113-b.1 pre

Nov 16, 2025

0.9.111 patch

Nov 04, 2025

0.9.110 patch

Oct 31, 2025

0.9.109 patch

Oct 30, 2025

0.9.108 patch

Oct 21, 2025

0.9.108-b.1 pre

Oct 21, 2025

0.9.106 patch

Oct 13, 2025

Activity

Reach

Details