GitHub Enterprise CVE-2026-3854: Git Push Hattındaki Kritik Açık İçin Müdahale Rehberi
GitHub, git push işleme hattını etkileyen CVE-2026-3854 numaralı kritik uzaktan kod çalıştırma açığının ayrıntılarını yayımladı. Açık, bir depoya push yetkisi bulunan kimliği doğrulanmış kullanıcının özel hazırlanmış bir push seçeneğiyle işlemi yürüten GitHub sunucusunda rastgele komut çalıştırabilmesine imkân verebiliyordu.
GitHub’ın açıklamasına göre sorun 4 Mart 2026 tarihinde hata ödül programı üzerinden bildirildi. Ekip raporu 40 dakika içinde yeniden üretti, aynı gün iki saatten kısa sürede github.com ortamına düzeltmeyi dağıttı ve olay incelemesine başladı. GitHub, bulut hizmetinde araştırmacıların testleri dışında istismar izi veya müşteri verisine erişim tespit etmediğini belirtiyor.
CVE-2026-3854 nasıl çalışıyordu?
Git push seçenekleri, istemcinin push işlemi sırasında sunucuya anahtar ve değer biçiminde ek bilgiler göndermesine izin veren meşru bir Git özelliğidir. GitHub’ın iç mimarisinde bu değerlerin bir bölümü, işlem ortamı ve depo türü gibi bilgileri taşıyan servisler arası meta veriye aktarılıyordu.
GitHub’ın açıklamasına göre kullanıcı girdisi iç protokolde kullanılan ayırıcı karakteri içerebiliyordu ve yeterli biçimde temizlenmiyordu. Böylece saldırgan aşağı akıştaki servisin güvenilir kabul ettiği ek alanlar enjekte edebiliyor, push işleminin yürütüldüğü ortamı değiştirebiliyor ve normalde komutları sınırlayan koruma alanını aşabiliyordu.
Kimler etkileniyor?
github.com, GitHub Enterprise Cloud, veri yerleşimli Enterprise Cloud ve yönetilen kullanıcı hesaplarına sahip bulut ortamları 4 Mart 2026 tarihinde sağlayıcı tarafından yamalandı. GitHub bu hizmetlerin kullanıcıları için ek bir işlem gerekmediğini söylüyor. Bulut müşterileri yine de kendi hesap ve depo erişim politikalarını düzenli olarak incelemelidir.
Asıl güncelleme sorumluluğu şirket içinde çalıştırılan GitHub Enterprise Server yöneticilerindedir. İstismar için saldırganın sunucudaki en az bir depoya push yetkisi bulunan kimliği doğrulanmış hesaba ihtiyacı vardır. Bu koşul riski ortadan kaldırmaz; ele geçirilmiş geliştirici hesapları, eski çalışan erişimleri veya gereğinden geniş depo izinleri saldırı yolunu açabilir.
Hangi GHES sürümleri güvenli?
GitHub, desteklenen sürüm kolları için yamaları 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 ve 3.20.0 sürümlerinde yayımladı. Bu numaraların her biri kendi sürüm kolundaki en düşük düzeltilmiş düzeyi gösterir; daha yeni yama sürümleri de ilgili düzeltmeyi içermelidir.
GHES yöneticileri kullandıkları ana sürüm kolundaki en güncel yama sürümüne mümkün olan en kısa sürede geçmelidir. Yalnızca güvenlik duvarı arkasında bulunmak yeterli değildir, çünkü saldırı koşulu internetten anonim erişim değil push yetkisidir. İç tehdit ve hesap ele geçirme senaryoları da değerlendirilmelidir.
- GHES 3.14 kullananlar 3.14.25 veya daha yeni sürüme geçmelidir.
- GHES 3.15 kullananlar 3.15.20 veya daha yeni sürüme geçmelidir.
- GHES 3.16 kullananlar 3.16.16 veya daha yeni sürüme geçmelidir.
- GHES 3.17 kullananlar 3.17.13 veya daha yeni sürüme geçmelidir.
- GHES 3.18 kullananlar 3.18.7 veya daha yeni sürüme geçmelidir.
- GHES 3.19 kullananlar 3.19.4 veya daha yeni sürüme geçmelidir.
- GHES 3.20 kullananlar 3.20.0 veya daha yeni sürüme geçmelidir.
Günlüklerde hangi işaret aranmalı?
GitHub, GHES müşterilerine ihtiyat gereği erişim günlüklerini incelemelerini öneriyor. Üreticinin verdiği özel kontrol, /var/log/github-audit.log dosyasında push seçenekleri içinde noktalı virgül karakteri bulunan işlemleri araştırmaktır. Bu gösterge tek başına saldırının başarıyla tamamlandığını kanıtlamaz; bağlam ve kullanıcı etkinliğiyle birlikte değerlendirilmelidir.
Şüpheli kayıt görüldüğünde ilgili hesabın oturumları, kişisel erişim belirteçleri, SSH anahtarları, IP adresleri ve hedef depolardaki değişiklikler zaman çizelgesine yerleştirilmelidir. Sistem günlükleri korunmalı ve inceleme tamamlanmadan aceleyle silinmemelidir. Olası komut çalıştırma durumunda sunucu üzerindeki kalıcılık mekanizmaları ve kimlik bilgisi erişimi de araştırılmalıdır.
Güncelleme öncesi ve sonrası müdahale
Yükseltme öncesinde desteklenen yedek alınmalı, sürüm notları kontrol edilmeli ve geri dönüş planı hazırlanmalıdır. Bakım penceresi, yalnızca hizmet kesintisini değil güvenlik açığının kapatılma aciliyetini de dikkate almalıdır. Yama kurulana kadar gereksiz push yetkileri kaldırılabilir ve ayrıcalıklı depolara erişim daraltılabilir.
Güncelleme sonrasında çalışan GHES sürümü arayüzden ve yönetim kayıtlarından doğrulanmalıdır. Yetki matrisi gözden geçirilmeli, uzun süredir kullanılmayan hesaplar kapatılmalı ve yönetici belirteçleri için asgari kapsam uygulanmalıdır. Eğer şüpheli kullanım saptanırsa yalnızca yamalamak yeterli olmaz; etkilenmiş kimlik bilgileri döndürülmeli ve olay müdahalesi yürütülmelidir.
- Çalışan GHES sürümünü ve destek kolunu belirleyin.
- Push yetkisi bulunan kullanıcı, bot ve entegrasyon hesaplarını çıkarın.
- Denetim günlüğünü noktalı virgül içeren push seçenekleri açısından inceleyin.
- Uygun sabit sürüme yükseltin ve sürüm bilgisini yeniden doğrulayın.
- Şüpheli hesapların oturumlarını sonlandırıp belirteç ve anahtarlarını yenileyin.
- Depo değişiklikleriyle sistem günlüklerini ortak bir zaman çizelgesinde inceleyin.
Olaydan çıkarılabilecek mimari dersler
GitHub, temel düzeltmenin kullanıcı kontrollü push seçeneklerini doğru biçimde temizlemek olduğunu belirtiyor. Şirket ayrıca saldırı zincirinin yararlandığı, mevcut ortamda çalışması gerekmeyen eski bir kod yolunu konteyner imajından kaldırdı. Bu ikinci adım, benzer bir girdi hatası gelecekte ortaya çıksa bile etkisini sınırlamayı amaçlıyor.
Bu yaklaşım savunma derinliğinin pratik örneğidir. Girdi doğrulama tek kontrol olarak bırakılmamalı; iç protokollerde güven sınırları açık olmalı, gereksiz kod üretim ortamına taşınmamalı ve olağandışı işlem yolları izlenmelidir. GitHub’ın olayı araştırabilmesini sağlayan belirgin telemetri, düzeltme kadar görünürlüğün de önemli olduğunu gösteriyor.