GitHub uzaktan kod çalıştırma açığı: CVE-2026-3854 analizi

• Yalnızca git push yolundaki dahili protokol kusuru üzerinden arka uçta uzaktan kod çalıştırma mümkündü; GitHub.com için azaltım zaten uygulanmış durumda, ancak GHES tarafında yama gerekiyor
• Kullanıcı denetimindeki push option değeri doğrudan X-Stat başlığına girdiği için tek bir noktalı virgülle yeni alan enjekte edilebiliyordu; aynı anahtarın sonraki değeri önceki değeri ezdiği last-write-wins davranışı da istismar edildi
• Enjekte edilebilen alanlar arasında rails_env, custom_hooks_dir, repo_pre_receive_hooks birlikte kullanılarak sandbox aşılabiliyor ve saldırganın belirlediği yoldaki hook'lar git kullanıcısı yetkileriyle çalıştırılabiliyordu
• Aynı mekanizma ile GitHub.com'un enterprise mode bayrağı da enjekte edilebildi; böylece shared storage node üzerinde kod çalıştırma doğrulandı ve o düğümdeki diğer kullanıcı ve kuruluş depolarının da okunabildiği bir duruma yol açtı
• Farklı servislerin paylaşılan biçime güvendiği çok servisli mimarilerde, girdi temizleme eksikliği, üretim dışı yürütme yolları ve yol doğrulama eksikliğinin birleşerek ciddi zafiyetlere dönüşebileceğini gösteriyor

---

Acil müdahale ve etki kapsamı

• GitHub.com tarafında bu sorun zaten azaltıldı; ek bir işlem gerekmiyor
• GitHub Enterprise Server için acil müdahale gerekiyor ve CVE-2026-3854 düzeltmesini içeren GHES 3.19.3 veya üstüne yükseltilmesi gerekiyor
• Etkilenen sürüm aralığı GHES 3.19.1 ve altı; düzeltilmiş sürümler olarak 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3 veriliyor
• Yazının hazırlandığı sırada GHES instance'larının %88'i hâlâ etkilenebilir durumdaydı
• GitHub'ın ek teknik bilgileri ve kurtarma prosedürleri GitHub güvenlik blogunda bulunabilir
• Wiz müşterileri, Wiz Threat Center'daki hazır sorgular ile savunmasız GHES instance'larını tespit edebilir

Araştırmanın arka planı ve yaklaşım

• GitHub'ın dahili git altyapısı, tüm git push işlemlerini işleyen bir yol ve birden fazla dahili servis farklı programlama dilleriyle yazılmış durumda
• Bu tür çok servisli yapılarda, her bileşenin paylaşılan veriyi ayrıştırma ve ona güvenme biçimindeki farklar zafiyetlere yol açabiliyor
• Daha önce bu pipeline'ı oluşturan büyük miktardaki derlenmiş kara kutu binary'leri çıkarmak ve denetlemek aşırı zaman ve el emeği gerektiriyordu
• AI destekli araçlar ve IDA MCP tabanlı otomatik tersine mühendislik sayesinde derlenmiş binary'ler hızlıca analiz edilip dahili protokol yeniden kurulabildi
• Bu süreçte, kullanıcı girdisinin tüm pipeline boyunca sunucu davranışını etkilediği noktalar sistematik olarak izlendi ve girdi akışındaki temel kusur ortaya çıkarıldı

Dahili mimari ve güven sınırları

• git push SSH üzerinden geldiğinde istek sırasıyla babeld, gitauth, gitrpcd ve pre-receive hook üzerinden ilerliyor
• babeld, tüm git işlemlerinin giriş noktası olarak SSH bağlantısını alıyor; kimlik doğrulama ise gitauth'a iletiliyor
• gitauth, kullanıcı kimlik bilgilerini ve deponun push yetkisini doğruluyor; dosya boyutu sınırları veya branch adı kuralları gibi güvenlik politikalarını geri döndürüyor
• babeld, bu yanıta dayanarak güvenlik metaverisi içeren dahili X-Stat başlığını oluşturuyor
• gitrpcd, X-Stat başlığını alıp sonraki süreç ortamını ayarlıyor ve herhangi bir ek doğrulama yapmadan tamamen babeld'ye güveniyor
• pre-receive hook, push kabul edilmeden önce dosya boyutu sınırlarını, branch adı kurallarını, LFS bütünlüğünü ve yönetici tanımlı özel hook'ları denetliyor
• Temel bağlayıcı unsur, ; ile ayrılan key=value çiftlerini taşıyan X-Stat başlığıydı
• Dahili servisler X-Stat'ı ; karakterine göre bölerek bir map dolduruyor; aynı anahtar iki kez gelirse sonraki değer önceki değeri eziyor; bu last-write-wins kuralı izleniyor
• babeld, git push -o ile iletilen push options değerlerini de push_option_0, push_option_1, push_option_count gibi alanlar olarak X-Stat içine ekliyordu

Zafiyetin nedeni: X-Stat alan enjeksiyonu

• babeld, kullanıcı denetimindeki push option değerini X-Stat başlığına kopyalarken noktalı virgülleri temizlemiyordu
• ;, X-Stat alan ayıracı olduğundan, push option içindeki tek bir noktalı virgül orijinal alanın dışına çıkıp saldırgan denetiminde yeni alanlar oluşturabiliyordu
• Örneğin push_option_0 içine large_blob_rejection_enabled=bool:false enjekte edilirse, daha önce ayarlanmış bool:true değeri sonraki değer tarafından ezilebiliyordu
• Bu davranış hem binary analizi sırasında hem de gerçek GHES instance'ları üzerindeki paket yakalamalarında doğrulandı
• Tersine mühendislik ve wire-level analizin birleşimiyle enjekte edilebilir X-Stat alanları haritalandı
• Özellikle güvenlik açısından kritik alanlar olarak rails_env, custom_hooks_dir, repo_pre_receive_hooks, large_blob_rejection_enabled, reject_sha_like_refs, user_operator_mode belirlendi
• Bunlar içinde rails_env, custom_hooks_dir, repo_pre_receive_hooks üçlüsü uzaktan kod çalıştırmaya götüren asıl unsurdu

GHES üzerinde RCE'ye giden yol

• GHES, push kabul edilmeden önce çalışan custom pre-receive hooks desteği sunuyor
• pre-receive binary'sinde, yalnızca X-Stat içindeki rails_env değerine göre ayrılan iki yürütme yolu vardı
• Değer production ise hook sandbox içinde çalıştırılıyor; başka bir değer ise sandbox veya izolasyon olmadan doğrudan git servis kullanıcısı yetkileriyle çalıştırılıyordu
• Bu nedenle rails_env alanına üretim dışı bir değer enjekte edilerek sandbox atlatılabiliyordu
• Ardından custom_hooks_dir enjekte edilerek hook script'lerinin aranacağı varsayılan dizin saldırganın denetimine bırakılabiliyordu
• Son olarak repo_pre_receive_hooks alanına path traversal içeren bir hook tanımı enjekte edildiğinde, binary'nin yol çözümlemesi saldırgan denetimindeki dizin ile traversal yükünü birleştirerek dosya sisteminde keyfi bir yolu hedefliyordu
• Üretim dışı yürütme yolu, bu şekilde çözümlenen yolu herhangi bir argüman olmadan, sandbox olmadan ve git servis kullanıcısı olarak doğrudan çalıştırıyordu
• Gerçek doğrulamada tek bir git push ile uid=500(git) çıktısı döndü ve böylece git kullanıcısı yetkileriyle RCE doğrulandı
• Bu yetkiyle, GHES instance'ının dosya sisteminde okuma-yazma ve dahili servis yapılandırmalarına görünürlük dahil tam denetim elde etmek mümkündü

GitHub.com'a genişleme ve tenant'lar arası maruziyet

• Aynı exploit zinciri GitHub.com deposuna uygulandığında ilk başta push başarılı oldu ancak custom hooks çalışmadı
• user_operator_mode=bool:true enjekte edilip iki platformun debug çıktıları karşılaştırıldığında, GitHub.com üzerinde custom hooks kod yoluna girilmediği görüldü
• Ek tersine mühendislikle, sunucunun enterprise mode davranışını kontrol eden bir boolean bayrağın X-Stat başlığında bulunduğu anlaşıldı
• GHES'te bu bayrak varsayılan olarak true olduğundan custom hooks yolu her zaman etkin; GitHub.com'da ise varsayılan değer false olduğu için normal durumda o yola ulaşılamıyor
• Bu bayrak da aynı mekanizma ile enjekte edilebildiğinden, bir alan daha eklenerek GitHub.com'da da tüm exploit zinciri çalıştırılabildi
• Sonrasında GitHub.com altyapısı içinden hostname komutunun çıktısı döndü ve GitHub.com RCE doğrulandı
• GitHub.com, çok kiracılı bir platform olduğu için farklı kullanıcı ve kuruluşların depoları paylaşılan arka uç altyapısında tutuluyor
• Kod çalıştırmanın gerçekleştiği yer bir shared storage node idi ve burada git kullanıcısı, o düğümdeki tüm depo işlemlerini yürütmek için geniş dosya sistemi yetkilerine sahipti
• Bu kullanıcının ele geçirilmesi, düğümdeki diğer kuruluş ve kullanıcıların depolarının da sahiplerinden bağımsız olarak okunabilmesi anlamına geliyordu
• Ele geçirilen iki düğümde erişilebilir depo dizin girdileri listelendiğinde, her düğümde milyonlarca girdi bulunduğu ve bunların başka kullanıcı ve kuruluşların depolarını da içerdiği görüldü
• Başka tenant depolarının gerçek içeriklerine erişilmedi; yalnızca kendi test hesapları kullanılarak git kullanıcısının dosya sistemi yetkilerinin düğümdeki tüm depoları okuma imkânı verdiği doğrulandı

Temel dersler ve açıklama takvimi

• Yalnızca tek bir git push ile dahili protokol kusuru istismar edilip arka uç altyapıda uzaktan kod çalıştırma mümkün olabildi
• Farklı dillerle yazılmış birden fazla servis paylaşılan bir dahili protokol üzerinden veri alışverişi yaptığında, servislerin güven varsayımları başlı başına saldırı yüzeyi hâline geliyor
• Bu zincirde, bir servis push option değerini olduğu gibi ekledi, başka bir servis X-Stat içindeki tüm alanlara güvendi ve pre-receive hook üretim ortamında rails_env değerinin production olacağını varsaydı
• Üretim binary'leri içindeki üretim dışı kod yolları, hook script'lerinde path traversal doğrulamasının olmaması ve ayraç tabanlı protokollerde girdi temizleme eksikliği; başka kod tabanlarında da görülebilecek kalıplar
• Çok servisli mimariler işleten ekiplerin, özellikle güvenlik açısından hassas yapılandırmalar paylaşılan veri biçimlerinden türediğinde, kullanıcı denetimindeki girdinin dahili protokol boyunca nasıl aktığını incelemesi gerekiyor
• Bu araştırmada IDA MCP dahil AI destekli tersine mühendislik araçları, derlenmiş binary analizini ve dahili protokolün yeniden kurulmasını ciddi biçimde hızlandırdı
• Bu tür araçlar olgunlaştıkça, derin bileşenler arası analiz gerektiren zafiyet sınıflarını bulmada daha da önemli bir rol oynayacak gibi görünüyor
• Açıklama takvimine göre 2026-03-04 tarihinde X-Stat push option enjeksiyon zafiyeti bulundu; aynı gün GHES 3.19.1 üzerinde RCE doğrulandı ve GitHub'a bildirildi; GitHub.com düzeltmesi de aynı gün devreye alındı
• 2026-03-10 tarihinde CVE-2026-3854 ve CVSS 8.7 atandı, GHES yaması yayımlandı
• 2026-04-28 tarihinde kamuya açıklandı