Rust Miri, CI sırlarını target/ dizinine yazdı ve GitHub Actions cache'leri bunları pull request'lere teslim etti

Ne oldu

21 Eylül 2026'da Rust projesi, dev.to'da bir yazıyla özetlenen bir güvenlik duyurusu yayınladı; duyuruda, Rust'ın tanımsız davranışı tespit etmek için kullandığı yorumlayıcı Miri'nin CI sırlarını GitHub Actions cache'lerine sızdırdığı anlatılıyor. Derlemeyle ilgili girdilerin çalıştırmalar arasında değişip değişmediğini fark etmek için cargo miri, başlatıldığı ortamı kaydediyordu ve yalnızca gerçekten ihtiyaç duyduğu değişkenleri değil, tümünü kaydediyordu. Bu anlık görüntü Cargo target/ dizinine yazılıyordu; çoğu Rust CI hattının actions/cache veya Swatinem/rust-cache ile tam olarak cache'lediği dizin de buydu.

Sonuç: bir Miri adımına ortam değişkeni olarak aktarılan herhangi bir sır, cache'lenen dizin içinde diske düşebiliyordu; sonraki bir pull request çalıştırması bu dizini geri yükleyip okuyabiliyordu. CVE atanmadı. 22 Eylül 2026 tarihli nightly toolchain bu davranışa son veriyor; Miri artık yalnızca CARGO_* değişkenlerini (CARGO_*_TOKEN hariç) ve OUT_DIR'i kalıcı hale getiriyor.

Sızıntı nasıl çalışıyordu

dev.to yazısına göre savunmasız desenin gerçekleşmesi için dört şeyin bir araya gelmesi gerekiyor: CI'da cargo miri çalıştıran bir workflow, o adıma ortam değişkeni olarak enjekte edilen bir sır, ardından cache'lenen target/ dizini ve bu cache'i okumasına izin verilen pull request'ler. Ne bir çökme, ne panic ne de ayrıntılı tanılama gerekiyor; sırrın test çıktısında veya loglarda görünmesi de gerekmiyor — onu adıma aktarmak, ortam anlık görüntüsünün target/ içine yerleştirmesi için yeterliydi.

Sonrasında hasarı GitHub Actions cache kapsamı veriyor. Bir workflow çalıştırması kendi dalında ve varsayılan dalda oluşturulan cache'leri geri yükleyebildiği için, ayrıcalıksız bir pull request çalıştırması, main'e yapılan ayrıcalıklı bir push tarafından yazılan bir cache'i geri çekebiliyor. Duyuru ayrıca, yazıya göre, bu yolla bir sır ele geçiren birinin izlerini silmek için yeni commit'ler push edebileceğine dikkat çekiyor; yani temiz görünen bir workflow logu, hiçbir şey olmadığının kanıtı değil.

Etkilenen projeler için temizlik

dev.to yazarının belirttiğine göre kalan iş savunma değil iyileştirme: 22 Eylül 2026 veya daha sonrası bir toolchain'e geçin, halihazırda depolanmış cache'leri silin ve kapsam dahilinde olan her şeyi rotate edin. Cargo registry'nin veya Miri sysroot'unun cache'lenmesi hiçbir zaman sorun değildi — sızdıran dizin target/ idi. İnceleme için GitHub'ın CLI'sı işe yarar: gh cache list ve gh cache download ile bir cache'i yerel makineye çekip temiz olduğunu varsaymadan önce içeriğini kontrol edebilirsiniz.

Sıkılaştırma adımları

Yazı, toolchain'i güncellemenin ötesinde birkaç değişiklik öneriyor:

• Üretim sırlarını Miri çalıştırmalarından tamamen uzak tutun; testlerin gerçekten bir kimlik bilgisine ihtiyacı varsa, gerçek izinleri olmayan, kapsamı dar ve iptal edilebilir bir sahte değer kullanın.

• Sır gören job'larda target/ dizinini cache'lemeyin — ya da bu job'lara baştan sır vermeyin. Miri için bir şey cache'leyecekseniz, sysroot'u standart bir derleme cache'iyle asla çakışmayacak ayrı bir anahtar altında cache'leyin ve yolu elle yazmak yerine rustc --print sysroot ile doğrulayın.

• Workflow'lara contents: read gibi üst düzey bir permissions bloğu ekleyin; böylece zehirlenmiş bir cache, bir çalıştırmanın gerçekten neler yapabileceğini sınırlar.

• Miri job'larını sır taşıyan job'lardan izole edin ve sırları yalnızca gerçekten ihtiyaç duyulan yerde, adım düzeyinde enjekte edin. Yazar ayrıca yaygın bir kopyala-yapıştır hatasını düzeltiyor: secrets: inherit yalnızca uses ile yeniden kullanılabilir bir workflow çağıran job'da geçerlidir, kendi adımlarını çalıştıran bir job'da değil.

• Cache'leri düzenli olarak denetleyin; örneğin workflow dosyalarında, paths değerleri sır enjekte edilen adımların yazdığı dizinlerle örtüşen actions/cache girdilerini arayın.

Neden önemli

Bu bir Rust kazası değil, bir hata sınıfı. Çağrıldığı ortamın anlık görüntüsünü derleme dizinine alan her araç aynı sızıntının adayıdır ve derleme dizinleri, tam olarak CI cache'lemesinin hedeflediği şeylerdir. Cache'ler, kendilerini oluşturan çalıştırmanın ömründen fazla yaşayan ve ortam değişkenlerinin geçemediği güven sınırlarını aşan kalıcı artefaktlardır — GitHub'ın kapsam kuralları, korumalı bir daldan oluşturulmuş bir cache'i bir pull request'e memnuniyetle teslim eder. Miri duyurusu, her hatta sorulacak iki basit soru için yararlı bir prompt: cache'lediğimiz şeyin içinde gerçekten ne var ve bunu geri yüklemeye kimin izni var?