Miri kopierte die ganze CI-Umgebung nach target/, Caches gaben sie weiter
Serguey Asael Shinder2 Min. LesezeitDas Rust Security Response Team hat am 21. September eine Mitteilung veröffentlicht, verfasst von Manish Goregaokar im Namen des Teams. Es geht um das Zusammenspiel von cargo miri mit dem Zwischenspeichern von Build-Verzeichnissen in der CI. Miri muss sich merken, welche buildrelevanten Umgebungsvariablen beim letzten Aufruf gesetzt waren, und der dafür gewählte Weg legte eine Kopie der Prozessumgebung im Verzeichnis target/ ab. Auf dem eigenen Rechner fällt das niemandem auf. In der CI, wo target/ zu den ersten Kandidaten für einen Cache gehört, ist es eine Kopie aller Werte, die der Job sehen konnte — Zugangstoken eingeschlossen.
Zur Preisgabe wird das durch den üblichen Zuschnitt eines GitHub-Actions-Caches. Empfohlen ist, dass Läufe auf main schreiben dürfen und Pull-Request-Läufe nur lesen; genau so verhindert man, dass Fremde den Cache vergiften. Hier ist die Leserichtung die gefährliche. Wer schon einmal einen Beitrag eingebracht hat, kann einen Pull Request öffnen, die CI starten lassen, den zwischengespeicherten target/-Baum auswerten und anschließend einen zweiten Commit darüberschieben. Überschriebene Commits zeigt die Oberfläche kaum an, Protokolle und verworfene Commits verschwinden nach einigen Monaten — der Versuch hinterlässt also fast nichts.
Der kurzfristige Patch bewahrt nur noch CARGO_*-Variablen auf, ausgenommen alles, was auf CARGO_*_TOKEN passt, dazu OUT_DIR. Die Mitteilung sagt ausdrücklich, dass der Fix zum Zeitpunkt der Veröffentlichung möglicherweise noch nicht im Nightly steckt und dass das Miri im Nightly vom 22. September 2026 das Verhalten nicht mehr zeigt. Ein Scan öffentlicher Repositories ergab ein tatsächlich betroffenes Projekt und sieben weitere, die zwar nicht verwundbar wirkten, aber vorsorglich angeschrieben wurden.
Betroffen ist, wer cargo miri in der CI ausführt, während Geheimnisse in der Job-Umgebung liegen, target/ über actions/cache oder swatinem/rust-cache zwischenspeichert und diesen Cache für Pull Requests lesbar hält. Empfohlen wird, den Cache zu leeren und mutmaßlich abgeflossene Geheimnisse zu tauschen. Als schnelle Gegenmaßnahmen nennt die Mitteilung: Cache für diesen Job abschalten, Geheimnisse auf Schritte ohne Miri beschränken oder Miri vorübergehend deaktivieren.
Was das bedeutet
Der Cache ist eine Vertrauensgrenze — nur hat kaum jemand sie je eingezeichnet. Ein Cache-Eintrag wird von einem Job geschrieben und von einem anderen gelesen, den Fremde auslösen können. Alles, was in einem zwischengespeicherten Verzeichnis landet, ist damit faktisch für jeden veröffentlicht, der einen Pull Request öffnen darf. Das ist eine Eigenschaft der Mechanik, nicht von Miri.
Miri ist ein Fall, nicht die Ursache. Dahinter steht die Annahme, die Prozessumgebung sei privates Arbeitsmaterial, das ein Build-Werkzeug nach Belieben auf die Platte schreiben darf. Die Mitteilung zieht selbst den allgemeinen Schluss: Auch Projekte ohne Miri sollten Geheimnisse aus jedem Job heraushalten, der einen für Pull Requests lesbaren Cache füllt. Cargo sichert nirgends zu, dass Umgebungsvariablen nicht in target/ landen.
Eine Prüfung lohnt sich sofort und kostet eine Minute. Jede Workflow-Datei öffnen und für jeden Job, der ein Build-Verzeichnis zwischenspeichert, fragen, ob irgendein Schritt dieses Jobs ein Geheimnis in env stehen hat. Wenn ja, gehören beide nicht in denselben Job — unabhängig davon, welches Werkzeug gerade schreibt.
Quelle: https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/