GitHub Actions : le cache de Miri garde vos secrets

Ce qui se passe

Le Rust Security Response Team a publié le 21 septembre 2026 un avis sur une fuite de secrets possible dans GitHub Actions. En cause : Miri, l'interpréteur qui détecte les comportements indéfinis. cargo miri l'invoque plusieurs fois de suite, et pour transmettre l'environnement de build d'un appel à l'autre, Miri écrivait toutes les variables d'environnement dans target/. Secrets compris.

Isolé, ce comportement n'est pas une faille. Couplé au cache de GitHub Actions, il le devient.

Le chemin de la fuite

Beaucoup de projets Rust mettent target/ en cache pour accélérer la CI. La configuration courante laisse main écrire dans le cache et les pull requests seulement le lire : cela protège de l'empoisonnement du cache, pas de sa lecture.

GitHub n'exige l'accord d'un mainteneur que pour la première pull request d'un contributeur ; ensuite, chaque push relance la CI. Quelqu'un qui a déjà fait accepter un changement peut donc extraire le contenu du cache, puis pousser un second commit qui efface la trace. L'interface masque parfois les commits écrasés, et journaux comme commits écrasés disparaissent au bout de quelques mois.

Êtes-vous concerné ?

Oui si les quatre conditions sont réunies :

• cargo miri tourne en CI ;
• l'étape qui l'appelle voit un secret en variable d'environnement — passé à l'étape, déclaré dans le env du workflow, ou conservé par une étape précédente ;
• le workflow met target/ en cache, en général via actions/cache ou Swatinem/rust-cache ;
• ce cache est lisible par les pull requests.

Le scan mené par l'équipe Rust a relevé un dépôt vulnérable et sept qui ne semblent pas l'être mais appellent la prudence ; leurs mainteneurs ont été contactés. L'équipe reconnaît que ce scan est imparfait : vérifiez vous-même.

Ce qu'il faut faire

1. Au choix : désactiver le cache de ce job, réserver les secrets aux étapes qui n'appellent pas Miri, ou suspendre Miri.
2. Vider le cache du dépôt, puis faire tourner les secrets qui ont pu fuir.

gh cache list
gh cache delete --all

Le correctif de court terme (rust-lang/miri#5337) ne conserve plus que les variables CARGO_*, hors CARGO_*_TOKEN, et OUT_DIR. Il arrive avec la nightly du 2026-09-22.

Ce que ça change, même sans Miri

L'avis déborde de son outil. Ni Cargo, ni Miri, ni Rust ne garantissent qu'une variable d'environnement ne finira pas dans target/, et un script de build peut très bien l'y écrire. Beaucoup d'outils considèrent l'environnement entier comme bon à poser sur le disque. La règle qui en découle vaut pour tous les langages : un job capable d'écrire dans un cache public ne doit avoir accès à aucun secret.

Problème signalé par Predrag Gruevski (OpenAI) ; le scan de l'écosystème a utilisé des crédits Codex fournis par OpenAI.

Source : GitHub Actions leaking secrets when Miri output is cached, Rust Security Response Team, blog Rust, 21 septembre 2026.