4 Mart 2026’da gerçek surata çarptı: Kritik bir uzak kod çalıştırma açığı bildirildi, kod gönderme işlemini sunucu tarafı bir sömürüye dönüştürebilecek kadar tehlikeli.
Bu, marjinal bir köşe vakası falan değildi; github.com’u, GitHub Enterprise Cloud’un çeşitli konfigürasyonlarını ve GitHub Enterprise Server’ı vurdu. İki saatten kısa sürede GitHub güvenlik ekibi açığı doğruladı, canlı servisi yamarladı ve adli incelemeye daldı. Buldukları ve tepkileri, modern güvenlik olay yönetiminde çarpıcı bir vaka çalışması sunuyor.
Sömürünün Yapısı
Temelde, kullanıcı tarafından sağlanan <a href="/tag/git-push/">git push</a> seçeneklerinin işlenme biçiminden kaynaklanıyordu. Git’in meşru bir özelliği olan bu seçenekler, istemcilerin sunucuya özel anahtar-değer dizgilerini iletmesine izin verir. Sorun neydi? GitHub’un servisler arası push bilgisini taşıyan iç metadata protokolü, kullanıcı girdisinde de çıkabilen bir ayraç karakteri kullanıyordu.
Bu, devasa bir gedik açtı. Saldırgan, bir depoya push erişimi olan —hatta yeni oluşturduğu— biri olarak uydurulmuş push seçenekleri enjekte edebilirdi. Bu enjekte alanlar, meşru iç metadata gibi davranarak alt servisleri kandırabilirdi. Şöyle düşünün: Masum görünümlü bir git push --set-upstream origin main --option='key=value' geçidi haline geliyor. Birkaç enjekte değeri zincirleyerek saldırgan yürütme ortamını yeniden yazabilir, kum havuzunu atlar ve —pat— GitHub sunucusunda rastgele komutlar çalıştırabilirdi.
Zafiyet, kullanıcı tarafından sağlanan git push seçeneklerinin bu metadata içinde nasıl işlendiğinden kaynaklanıyor. Push seçenekleri, git’in kasıtlı bir özelliği; push sırasında istemcilerin sunucuya anahtar-değer dizgileri göndermesine olanak tanır. Ancak kullanıcı değerleri, yeterli temizleme yapılmadan iç metadata’ya katılmış.
Bu erişim seviyesi, her platform sağlayıcısı için kabus. Olağan savunma katmanlarını atlıyor, kod değişikliklerinin giriş noktasını doğrudan hedefliyor.
Işık Hızında Tepki
Zafiyet kadar çarpıcı olan bir şey de GitHub’un hızı. 4 Mart’ta gelen hata ödülü raporunu alır almaz, güvenlik ekibi 40 dakikada sorunu içerde yeniden üretti. Saat 17:45 UTC’de kök nedeni buldular. Kullanıcı push seçenekleri için kritik temizleme güncellemesi, saat 19:00 UTC’de github.com’a yayıldı — akıl almaz bir çeviklik.
GitHub Enterprise Server müşterileri için tüm desteklenen sürümlere yamalar hazırlandı ve bir CVE (CVE-2026-3854) yayınlandı. Tavsiye net: Hemen yükseltin.
Hayalet Avı: Sömürü Peşinde
Canlı servisteki anlık tehdit savuşturulunca, asıl kritik soru kaldı: Bulunmadan önce sömürülmüş müydü? GitHub soruşturması, sömürünün benzersiz bir özelliğinden yararlandı.
Sunucuyu GitHub.com’un normal işlemlerinde asla kullanılmayan bir kod yoluna zorluyordu. Bu, sinsi bir hata değildi; enjeksiyon mekanizmasının kaçınılmaz, gürültülü sonucu. Bu anomali yolu kaydedip sorgulayarak GitHub, yetkisiz etkinlik olup olmadığını kesin belirledi. Telemetri su gibi net: O yolun her tetiklenmesi Wiz araştırmacılarının kendi testlerine dayanıyordu. Başka kullanıcı yok, müşteri verisi erişilmedi, değiştirilmedi ya da sızdırılmadı. Enterprise Server için iş müşterilere kaldı; sömürü, o örnekteki doğrulanmış push erişimi gerektirir, erişim günlüklerini kontrol edin.
Katmanlı Savunma: Yamadan Fazlası
Doğrudan düzeltmenin ötesinde, GitHub’un analizi katmanlı savunmanın kritik dersini ortaya koydu. Sömürü kısmen, olmaması gereken ortamlarda diskte tehlikeli bir kod yolunun bulunmasından başarılı oldu. Eski dağıtım yöntemi bunu doğru dışlamıştı ama sonraki strateji değişikliği farkında olmadan geri getirmişti.
İşte mimari düşüncenin devreye girdiği yer. Bırakın alakasız gibi görünen sistem ayarlarının nasıl yeni zafiyetler doğurabileceğini gösteriyor. Bu gereksiz kod yolunu hedeflenmeyen ortamlardan kaldırarak GitHub bir katman daha güçlendirdi. Pragmatik yaklaşım: Anlık ihlali kapat, etrafındaki duvarları pekiştir ki benzer girişler bile zorlaşsın.
Siz Ne Yapmalısınız?
GitHub Enterprise Server kullanıcıları için mesaj net: Yükseltin. CVE-2026-3854 detaylarını öğrenin, desteklenen sürümlere yamaları uygulayın. Erişim günlüklerini alışılmadık etkinlik için gözden geçirmek de akıllıca.
Genel geliştiriciler içinse güçlü bir uyarı bu. Günde yüzlerce kez düşünmeden yaptığımız git push işlemi, karmaşık güvenlik sonuçları gizleyebiliyor. Alt protokolleri ve girdilerinizin nasıl işlendiğini anlamak her zaman en önemlisi. Bu olay sadece bir hata değil; köklü araçların bile sürekli dikkat ve derin mimari anlayış gerektirdiğini gösteren keskin bir örnek.
SSS
CVE-2026-3854 zafiyeti GitHub Enterprise Server kullanıcıları için ne anlama geliyor?
GHES örneğinizdeki bir depoya push erişimi olan kullanıcılar sunucuda rastgele komut çalıştırabilirdi. GitHub yamalı sürümlere hemen yükseltmeyi şiddetle öneriyor.
GitHub.com’da verilerim bu zafiyetten etkilendi mi?
Hayır. GitHub soruşturması, sömürü yolunun sadece araştırmacılar tarafından tetiklendiğini doğruladı; müşteri verisi erişilmedi, değiştirilmedi ya da sızdırılmadı.
Düzeltmeden sonra git push seçeneklerini kullanmaya devam edebilir miyim?
Evet, git push seçenekleri desteklenmeye devam ediyor. Düzeltme, kullanıcı değerlerinin düzgün temizlendiğini ve kötü niyetli komut enjeksiyonuna izin vermediğini garanti ediyor.
