Read-only Miri caches can still disclose secrets
The Miri advisory separates cache confidentiality from write permissions. Follow the exposure conditions while preserving useful CI caching where appropriate.
By 
Paul. Architecture and infrastructure
Looking back from November 2026 at the week of 16 September, the Miri advisory makes a precise case for separating two properties of a build cache. Preventing an outside contributor from changing cached files protects integrity. It does not establish that those files are safe for that contributor to read. Teams should decide what may enter a shared cache by examining its inputs and intended readers together. A read-only permission says too little about confidentiality to settle that decision.
The Rust advisory of 21 September describes four conditions together: CI runs cargo miri; that step has secrets in environment variables; the workflow caches target/; and pull requests can access that cache. Secrets may reach the step directly, through workflow-level environment settings, or through an earlier step that persists them. The vulnerable Miri behavior saved the environment under target/. Those conditions explain the disclosure route without declaring every Rust cache vulnerable.
Follow the data across runs
The important boundary in this account lies between the run producing an artifact and a later run reading it. A secret need not be handed directly to the pull request for the later run to learn it. If a privileged environment becomes part of a reusable directory, permission to restore that directory can carry information across the boundary. Reviewing only the environment of the receiving job would miss the earlier serialization of the secret. The producer's behavior matters as much as the consumer's credentials.
This gives technical leaders a more useful review question than whether contributors have cache write access. Which processes contributed files to the directory, what information could those processes read, and who can restore their output? These are proposed review questions, rather than claims that any particular repository is exposed. They also keep the scope distinct from reviews of privileged workflow triggers. The issue here is the information already inside a reusable artifact, even when the later job cannot poison it.
A cache key helps a build find an artifact, but its descriptive name cannot establish the sensitivity of the artifact's contents. Calling a directory a dependency cache does not change what a tool wrote there. For planning purposes, the ownership of a cache should include ownership of that content assumption. Otherwise a change to one build step can silently invalidate an assumption made when another team first enabled reuse. The configuration may look unchanged while the information flowing through it has changed.
A dated fix has a narrower meaning
The Miri change merged on 21 September narrowed which environment variables were preserved. The advisory describes preservation of CARGO_*, excluding CARGO_*_TOKEN, and OUT_DIR; it identifies the upcoming 22 September nightly as the delivery point. That is the dated advisory's account of the fix. A merge and an announced nightly do not prove that a repository's installed toolchain contains it, nor do they establish that an older cache has disappeared.
That distinction matters when someone asks whether an upgrade finishes the work. The software creating future artifacts and the artifacts already stored are different objects. In its response guidance, the advisory includes clearing the cache and considering rotation of potentially leaked secrets. These are the maintainers' recommendations for the described exposure, not operations performed here. An operational decision would still need evidence about the affected workflow and its retained artifacts. A reassuring version label alone cannot answer that historical question.
Keep the speed argument honest
The strongest objection to separating or reducing cache reuse is practical. Rebuilding the same dependencies can delay feedback and consume CI capacity. Shared caches can retain substantial value when their contents are suitable for their readers. The advisory does not justify removing every cache, and an indiscriminate shutdown can leave a team with slower builds while obscuring the particular producer that wrote sensitive data. A focused response preserves the distinction between useful reuse and an unsafe information path.
A reasonable maintenance discussion therefore compares specific alternatives. Could the relevant tool run without receiving the secret? Could the reusable output be separated from output produced with privileged inputs? Does the actual toolchain address the documented behavior? These are design options to assess against the real workflow, rather than universal instructions to copy into every project. Where the four advisory conditions do not hold together, this particular exposure has not been established. Other tools and other disclosure paths require their own evidence.
The business consequence is an ownership problem as well as a technical one. Build speed is visible in job duration; the confidentiality assumption behind reuse is easier to leave undocumented. A maintenance budget should allow someone to keep both under review when build tooling changes. That does not promise a quantified saving or prove an incident occurred. It gives the team a concrete responsibility: explain why the shared output is appropriate for everyone allowed to retrieve it.
For teams considering software maintenance, this is a useful boundary to include in the agreed work. Cache ownership should cover the information written by producers and the access granted to later readers. Keep the cache where that account holds. Where it does not, change the information path and assess the historical exposure on its own evidence. The permission to read deserves an explicit decision, even when the permission to write has already been restricted.