GitHub Actions filtra secretos cuando la caché de Miri guarda el entorno
Miri volcaba todas las variables de entorno a target/, y con la caché de Actions ese directorio queda legible desde cualquier pull request. Rust ya ha parcheado el comportamiento.
El equipo de respuesta de seguridad de Rust ha corregido un comportamiento de Miri que acababa filtrando secretos a través de la caché de GitHub Actions. Miri escribía todas las variables de entorno en target/, y quien cachee ese directorio y lo deje legible desde pull requests estaba regalando cualquier token presente en el entorno del job. La corrección limita lo que se persiste a las variables CARGO_* (salvo CARGO_*_TOKEN) y OUT_DIR.
Miri necesita conservar entre ejecuciones las variables relevantes para la compilación, y hasta ahora lo resolvía volcando el entorno completo a disco. Por sí solo no es una vulnerabilidad: el problema aparece al combinarlo con cómo cachea Actions. Las ramas principales escriben en la caché, las PR solo leen, y ese es el modelo de seguridad asumido. Cualquiera que pueda abrir una PR (y que ya haya tenido un cambio aceptado antes, porque GitHub solo exige aprobación del mantenedor para la primera) puede lanzar CI sobre esa caché y extraer lo que haya dentro. Después empuja un segundo commit y el anterior queda oculto en la interfaz, además de borrarse junto a los logs pasados unos meses.
Cómo saber si te toca
Las condiciones se acumulan: ejecutas cargo miri en CI; ese paso tiene secretos como variables de entorno, ya sea inyectados en el propio step, definidos en el env del workflow o arrastrados de un paso previo; el workflow cachea target/, normalmente con actions/cache o swatinem/rust-cache; y esa caché es legible desde PRs.
Si es tu caso, las salidas rápidas pasan por desactivar la caché en ese job, acotar los secretos a los pasos que no llaman a Miri o desactivar Miri de forma temporal. Después toca limpiar la caché y rotar los secretos que hayan podido quedar ahí.
El parche está en revisión en el pull request de rust-lang/miri, aunque el propio equipo avisa de que puede no haber llegado todavía al nightly. La nightly del 2026-09-22 es la primera sin el problema. El escaneo que hicieron sobre repositorios de GitHub encontró uno afectado y otros siete que no parecen vulnerables pero a los que recomiendan revisarse; a los mantenedores se les ha avisado. Admiten que el escaneo es imperfecto.
La parte incómoda, y que trasciende a Miri: cargo no garantiza que las variables de entorno se queden fuera de target/, y un build script puede hacer con el entorno lo que le convenga. Según el equipo, no hay que fiarse de que los artefactos de compilación no lleven secretos pegados. Cualquier job que escriba en una caché pública y tenga secretos en el entorno está en la misma posición, use Miri o no.
El fallo lo reportó Predrag Gruevski, de OpenAI. El escaneo del ecosistema se hizo con Codex y créditos donados por OpenAI. El triaje corrió a cargo de Manish Goregaokar, Ralf Jung, Ben Kimock, Weihang Lo, Jacob Finkelman, Walter Pearce, Josh Stone y Mark Rousskov.
