Herkes GitHub‘ı adeta bir kale gibi bekliyordu. Olması gereken de buydu. Sonuçta dünyanın tüm kodu orada yaşıyor. Dolayısıyla, kritik bir uzaktan kod çalıştırma açığının ödül programlarına düştüğünü duyduğumuzda, tüm teknoloji dünyasında duyulan kolektif nefes kesilmesi pek de abartı sayılmazdı.
Ama işte burada ilginç bir nokta var: Halledilmiş. Hızlıca. Ve görünüşe göre kimse içeri girmek için bu zafiyeti kullanmamış. Haber bu, ve bu her şeyi değiştiriyor, değil mi? Anlatıyı yaklaşan kıyametten kıl payı kurtuluşa, şaşırtıcı derecede temiz bir sonla biten uyarıcı bir hikayeye çeviriyor.
Binlerce Paniği Tetikleyen Rapor
Her şey 4 Mart 2026’da başladı. Muhtemelen daha çok duyacağınız bir isim olan Wiz’den araştırmacılar, depoya ‘push’ izni olan herhangi bir kullanıcının GitHub sunucularında rastgele komutları çalıştırabilmesine olanak tanıyan bir yöntemini detaylandıran bir rapor yayınladılar. Sadece tek bir komut, <a href="/tag/git-push/">git push</a>, özel olarak hazırlanmış bir seçenekle. Basit. Korkutucu.
Bu, kimsenin pek umursamadığı teorik bir bug değildi. Bu doğrudan erişimdi. Bir gökdelenin her kapısını açan anahtarı bulmak gibi düşünün. github.com, bulut hizmetleri ve hatta kendi kendine barındırılan Enterprise Server için sonuçları, en hafif tabirle, ciddiydi.
Bunu Nasıl Yaptılar?
Açığın kendisi, kontrolsüz girdinin klasik bir örneği. git push yaptığınızda, etrafta bolca metaveri dolaşır. Departmanlar arasında talimat taşıyan dijital bir kurye gibidir. Peki sorun ne? İç meta veri protokolünde kullanılan bir karakter, kullanıcı girdisinde de yer alabiliyormuş. Bunu bilen bir saldırgan, sistemin kesinlikle çalıştırmaması gereken kodu çalıştırması için kandırarak kendi talimatlarını enjekte edebiliyormuş. Bu, sanal ortamları aşmış. Kuralları yeniden yazmış. Her şeye göre, korkunçluğunda zarifmiş.
Müdahale: Kurşun Hızından Hızlı (Neredeyse)
İşte burada GitHub’ın müdahalesi parlıyor. Raporun üzerinden 40 dakika geçmeden hatayı tekrarlayabilmişler. İki saatten kısa bir süre sonra github.com üzerinde düzeltme yayındaydı. Bu sadece hızlı değil; etkileyici. Kendi kendine barındırılan Enterprise Server müşterileri için yamalar hazırlanıp yayınlanmış. CVE-2026-3854 tanımlayıcısı bu. GHES kullanıyorsanız, güncelleyin. Hemen.
Açık, sunucuyu
github.com‘daki normal operasyonlar sırasında asla kullanılmayan bir kod yolunu izlemeye zorluyor. Bu, enjeksiyonun nasıl çalıştığının doğal bir sonucu olduğu için bir saldırganın kaçınabileceği veya engelleyebileceği bir durum değil.
Milyon Dolarlık Soru: İstismar Edildi Mi?
Bu, güvenlik ekiplerini uykusuz bırakan kısım. Bu, Wiz’den önce mi keşfedildi? Başka biri bu dijital anahtarı bulup rapor edilmeden önce kullandı mı? GitHub’ın telemetri verileri hayır diyor. Açığın gerektirdiği belirli, anormal kod yolunu takip etmişler. O yolu tetikleyen her tekil örnek? Tamamen Wiz araştırmacılarının kendisiydi, yokluyorlardı.
Bu sadece bir PR açıklaması değil; bu değerli bir teknik detay. Açık o kadar belirgindi ki, yalnızca kendisi tarafından tanımlanabilen dijital bir iz bırakmış. GHES kullanıcıları için hesap biraz farklı; kimliği doğrulanmış bir kullanıcı gerektiriyor. Erişim günlüklerinin gözden geçirilmesi önerilir, ancak bulut tarafı temiz görünüyor.
Derinlemesine Savunma: Sadece Bir Moda Kelime Değil
Acil düzeltmenin ötesinde GitHub başka bir şey daha bulmuş. Açık, kısmen, farklı bir ortam için tasarlanmış bir kod parçacığının sunucuda oturuyor olması nedeniyle çalışmış. Eski bir dağıtım yöntemi bunu doğru bir şekilde hariç tutmuştu, ancak dağıtım uygulamalarındaki bir değişiklik tekrar içeri sızmasına izin vermişti. Bu, insanların bahsettiği “derinlemesine savunma”dır. Girdi temizleme düzeltmesi birincil öncelikti, ancak o gereksiz kodu kaldırmak başka bir katman ekliyor. Kapınızda bir kilit ve ayrıca bir güvenlik sistemi olması gibi. Biri başarısız olabilir, ancak umarım diğeri yakalar.
Bu olay, fiili istismar açısından engellenmiş olsa da, güçlü bir hatırlatıcı görevi görüyor. Güvendiğimiz sistemlerin bile sürekli tetikte olması gerekiyor. Ve bazen, en kritik dersler feci ihlallerden değil, kendi uygulamalarımızı daha derinlemesine incelemeye zorlayan kıl payı kurtuluşlardan gelir. GitHub’ın şeffaf raporu iyi bir başlangıç. Umarım sektör dikkate alır.
Sıkça Sorulan Sorular
Bu güvenlik açığı kendi kendine barındırılan GitHub Enterprise Server’ımı etkileyecek mi?
Evet, etkileyebilir. GitHub, GitHub Enterprise Server’ın (GHES) desteklenen tüm sürümleri için yamalar yayınladı ve derhal yükseltme yapılmasını şiddetle tavsiye ediyor. CVE tanımlayıcısı CVE-2026-3854.
Saldırganlar GitHub’dan herhangi bir veri çaldı mı?
GitHub’ın soruşturması ve telemetri verilerine göre, güvenlik açığının yetkisiz taraflarca istismar edildiğine dair hiçbir kanıt bulunmuyor ve sonuç olarak müşteri verileri erişilmedi, değiştirilmedi veya sızdırılmadı.
GitHub neden bu kadar hızlı yanıt verdi?
GitHub’ın güvenlik ekibi, hata raporunu 40 dakika içinde doğruladı ve raporu aldıktan sonra iki saat içinde github.com‘a bir düzeltme dağıttı. Bu hızlı yanıt, ödül programı ve hızlı bir iç doğrulama süreci ile mümkün oldu.
🧬 İlgili İçgörüler
- Daha fazlasını okuyun: Forem’i Kurtarmak İçin Silmek: Açık Kaynak Absürtlüğünü Ortaya Çıkaran Nisan Bir Nisant PR’ı
- Daha fazlasını okuyun: Q Günü Yaklaşıyor: Kriptografik Algoritmalar Kuantum Reckoning ile Karşı Karşıya
