GitHub'da Kritik Kod Yürütme Açığı Nasıl Engellendi?

GitHub, 4 Mart 2026 tarihinde Wiz araştırmacıları tarafından bildirilen ve şirketin altyapısını etkileyebilecek kritik bir uzaktan kod yürütme açığını yalnızca iki saatte tespit edip çözdü. Saldırganlar, basit bir git push komutu ile sunuculara sızma girişiminde bulunabiliyordu. Peki, bu tehlikeli açık nasıl keşfedildi ve hangi adımlarla kapatıldı?

Kritik Açığın Rapor Edilmesi

Wiz araştırmacıları, GitHub'ın Hata Ödülü Programı üzerinden ulaştıkları bildirimde, depolara push erişimi olan herhangi bir kullanıcının, özel olarak hazırlanmış bir git push komutu ile sunucularda istedikleri komutu çalıştırabileceğini belirtti. Saldırı için gereken tek şey, saldırganın kendisine ait bir depo oluşturması ve içine zararlı komutları gizlemesiydi.

GitHub güvenlik ekibi, raporu aldıktan sadece 40 dakika sonra açığın varlığını doğruladı ve ciddiyetini onayladı. Bu, anında müdahale gerektiren bir durumdu. Ekip, saldırının temelini anlamak için hızlı bir şekilde çalışmaya başladı.

Açığın Arka Planı: Nasıl İşledi?

GitHub'a yapılan bir git push işlemi, arka planda birçok hizmetten geçerek işlenir. Bu süreçte, depo türü ve işlemin gerçekleşeceği ortam gibi metadata bilgileri, iç protokoller aracılığıyla hizmetler arasında iletilir. Ancak araştırmacılar, kullanıcı tarafından gönderilen push seçeneklerinin (push options) bu metadata içinde yeterince temizlenmediğini keşfetti.

Push seçenekleri, Git'in istemcilerin sunucuya anahtar-değer çiftleri göndermesine izin veren bir özelliğidir. Ne var ki, kullanıcı tarafından gönderilen değerler, metadata formatındaki ayraç karakterleriyle çakışabiliyordu. Bu da saldırganların, metadata içine ek metadata enjekte etmesine olanak tanıyordu. Saldırganlar, zincirleme olarak enjekte edilen değerlerle, işlemin yürütüleceği ortamı değiştirebiliyor, koruma mekanizmalarını atlatabiliyor ve nihayetinde sunucuda istedikleri komutu çalıştırabiliyordu.

Hızlı Müdahale ve Kapatma Süreci

GitHub ekibi, 4 Mart 2026 saat 17.45 UTC'de açığın temel nedenini tespit etti ve aynı gün saat 19.00 UTC'de github.com adresine bir düzeltme yayınladı. Düzeltme, kullanıcı tarafından gönderilen push seçeneklerinin metadata içindeki değerleri etkilemesini engelleyerek, input temizlemeyi sağladı.

GitHub Enterprise Server (GHES) kullanıcıları içinse, desteklenen tüm sürümlerde (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4 ve 3.20.0+) yamalar yayınlandı. Bu yamalar, CVE-2026-3854 olarak kaydedildi ve kullanıcıların mümkün olan en kısa sürede güncelleme yapmaları şiddetle tavsiye edildi.

Saldırı Girişiminin İncelenmesi

GitHub, açıktan yararlanılıp yararlanılmadığını araştırmak için derinlemesine bir inceleme başlattı. Araştırmacılar, bu açığın yalnızca normal işlemler sırasında kullanılmayan bir kod yolunu zorunlu olarak çalıştırdığını belirtti. Bu da, saldırının loglarda kendini açıkça belli edeceği anlamına geliyordu.

Ekip, bu özel kod yolunu izlemek için telemetri verilerini taradı ve elde edilen sonuçlar net oldu:

• Tüm kayıtlar, yalnızca Wiz araştırmacıları tarafından yapılan testlere ait aktivitelere karşılık geldi.
• Başka hiçbir kullanıcı veya hesap bu kod yolunu tetiklemedi.
• Müşteri verileri, açıktan kaynaklanan herhangi bir şekilde erişilmedi, değiştirilmedi veya dışarı çıkarılmadı.

GHES kullanıcıları içinse, saldırı yalnızca depo içinde push yetkisine sahip bir hesabın varlığına bağlıydı. Şirket, kullanıcıların temkinli olmak adına erişim kayıtlarını incelemelerini önerdi.

Derinlemesine Savunma: Ek Önlemler

Acil input temizleme düzeltmesinin yanı sıra, araştırma süreci ek bir keşfe de yol açtı. Saldırı, sunucunun çalıştığı ortam için tasarlanmamış bir kod yoluna erişim sağladığı için mümkün olmuştu. Bu kod yolu, sunucunun container görüntüsünde yer alıyordu, ancak farklı bir ürün yapılandırmasında kullanılmak üzere tasarlanmıştı. Eski bir dağıtım yöntemi bu kodu doğru bir şekilde hariç tutarken, dağıtım modeli değiştirildiğinde bu hariç tutma devam ettirilmemişti.

Bu durum, derinlemesine savunmanın önemini bir kez daha gözler önüne serdi. Input temizleme düzeltmesi birinci derecede kritik olsa da, gereksiz kod yollarının da uygun ortamlardan kaldırılması gerekiyor. Gelecekte benzer bir açıklık keşfedilse bile, bu ekstra sertleştirme saldırganların hareket alanını sınırlayacaktır.

Ne Yapmalısınız?

GitHub Enterprise Cloud, GitHub Enterprise Cloud with Enterprise Managed Users, GitHub Enterprise Cloud with Data Residency ve github.com adresleri 4 Mart 2026 tarihinde yamalandı. Bu hizmetleri kullanan kullanıcıların herhangi bir işlem yapmasına gerek yok.

GHES kullanıcıları içinse saldırı, depo içinde push yetkisine sahip bir hesabın varlığını gerektiriyor. Kullanıcılara, push seçeneklerinde ; karakterini içeren işlemleri /var/log/github-audit.log dosyasından incelemeleri öneriliyor. Güncellemeler aşağıdaki sürümlerde mevcut:

• GitHub Enterprise Server 3.14.25 ve üzeri
• GitHub Enterprise Server 3.15.20 ve üzeri
• GitHub Enterprise Server 3.16.16 ve üzeri
• GitHub Enterprise Server 3.17.13 ve üzeri
• GitHub Enterprise Server 3.18.7 ve üzeri
• GitHub Enterprise Server 3.19.4 ve üzeri

GitHub, gelecekte benzer risklerin önüne geçmek için sürekli olarak altyapısını güçlendirmeye devam edecek. Bu süreçte, kullanıcıların güvenlik güncellemelerini takip etmeleri ve en iyi uygulamaları uygulamaları önem taşıyor.