Retrieved article excerpt
Open article · Retrieved 2026-09-21T21:23:06.255037+00:00
## GitHub Actions leaking secrets when Miri output is cached
Sept. 21, 2026 · Manish Goregaokar
on behalf of [security-response](https://www.rust-lang.org/governance/teams/#team-security-response)
The Rust Security Response Team was notified that Miri stores all environment variables to `target/`, allowing secrets to persist in caches.
While not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.
## Overview
GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on `main` (and other branches) to *write* to cache, and PRs can only *read* from cache (preventing cache poisoning). Rust projects tend to speed up CI by caching binaries built by `cargo install` and sometimes the contents of `target/`.
PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the *first* PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached `target/` and then cover their tracks by pushing a second commit to the PR.
GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect. CI run logs and overwritten commits are also deleted after a few months.
When `cargo miri` is invoked, Miri needs to retain build-relevant environment variables between runs[1](https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/#fn-1). The current code to do so achieves this by storing [all environment variables to `target/`](https://github.com/rust-lang/miri/blob/165a9c3c96f0f4e6232278e62cb64648215bbc37/cargo-miri/src/util.rs#L40-L42). This, of course, persists when `target/` is cached.
If your environment contained secrets, these can now be accessed by PRs via the cache.
## Our fix
Our [short term fix](https://github.com/rust-lang/miri/pull/5337) for this is to make Miri only preserve `CARGO_*` environment variables (excepting `CARGO_*_TOKEN`) and `OUT_DIR`. In the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables. Note that this patch may not be available on nightly yet.
We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.
## Am I affected?
It is likely that our scan was imperfect, so we recommend you check your own GitHub Actions setups if you run Miri.
You are vulnerable if:
- You run `cargo miri` in CI
- The step that runs `cargo miri` [has access to secrets](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets#using-secrets-in-a-workflow) as an environment variable:
- By being passed in to the step itself as an environment variable
- By being set in `env` for the workflow
- By being passed in to a previous step that persists it in the environment somehow
- The workflow being used caches the `target` directory, usually done via [`actions/cache`](https://github.com/actions/cache) or [`swatinem/rust-cache`](https://github.com/swatinem/rust-cache)
- The cache is accessible to PRs (common and often the intended use case)
Possible quick fixes include:
- Disabling cache for that job.
- Scoping secrets to steps in that job that do not call Miri.
- Temporarily disabling Miri.
Once done, [please clear the cache](https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manage-caches#deleting-cache-entries). Consider rotating any secrets that might have leaked.
The Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.
**Even if you do not run Miri,** ensure jobs that can write to public caches do not have access to secrets. Many tools do not have special handling for secrets, and assume the entire environment can be written to the filesystem.
## Threat model
We consider it bad practice to have a cache that can easily be tainted by secrets.
If caching `target/`, it is worth making sure that the inputs to processes that create `target/` (anything invoking `cargo`) do not have secrets available. It is generally rare for standard `cargo` build/test subcommands to need any secrets or tokens[2](https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/#fn-2), so this is mostly a matter of being careful about having secrets exposed as environment variables to the entire job.
Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into `target/`. While we are treating this as a security issue and patching it out of an abundance of caution, this is not something you should rely on in general. Beyond official Rust tooling, it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts.
## Acknowledgements
Thanks to [Predrag Gruevski](https://github.com/obi1kenobi) of OpenAI for reporting this issue to us. Furthermore, the ecosystem scan was performed using Codex access and credits donated by OpenAI, which we also thank them for.
Issue triage and remediation was performed by Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone, and Mark Rousskov.
1. Miri is invoked multiple times by `cargo miri` for complicated reasons [↩](https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/#fr-1-1)
2. In theory it could come up with build scripts reading from the network [↩](https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/#fr-2-1)