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

 (wiz.io)
2 puan yazan GN⁺ 2026-04-29 | 1 yorum | WhatsApp'ta paylaş
  • 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ı

İlgili okumalar

1 yorum

 
GN⁺ 2026-04-29
Hacker News görüşleri

  • Dahili kimlik doğrulama hizmeti tarafından ayarlanan kritik güvenlik başlıklarına,
    son kullanıcının git push -o ile verdiği rastgele bir dizgeyi de sokmuşlar
    Sonradan konuşmak kolay ama bu yine de fazla absürt

  • Yapay zeka destekli tersine mühendislik yaklaşımı, mevcut LLM ajanlarının güçlü yanlarını iyi gösteriyor
    Kodla yoğun biçimde eğitilmiş modeller, karmaşık sistemlerin içini anlama hızını inanılmaz artırabiliyor
    Güvenlik araştırması genelde 1) karmaşık iç işleyişi çözmek ve 2) bunun içinde zafiyet bulmak işlerinin üst üste gelmesinden oluşuyor,
    ama bazen gerçek iç mekanizma bir kez ortaya çıkınca zafiyetin kendisi şaşırtıcı derecede kolay görünebiliyor
    CVE-2026-3854 için durum, içi bilseniz bile hemen apaçık görülen bir tür değildi,
    ama daha geleneksel ya da erişimi kolay bir saldırı yüzeyinde olsaydı bu komut enjeksiyonu çok daha çabuk bulunurdu diye düşünüyorum

    • Başta yapay zekanın C++ tersine mühendisliğinde ya da C++ kodunu büyük ölçekte daha basit C'ye taşımada güçlü olduğuna dair işaretler vardı
      Ama son zamanlarda bu akış biraz bozulmuş gibi, ya da C++ sözdiziminin karmaşıklığından doğan geliştirici/vendor lock-in'i korumak isteyen taraflar yüzünden bilerek engelleniyormuş hissi veriyor

  • Sanki Wiz'de çalışan biri varmış gibi sonuçlar epey iyi görünüyor
    Ürün de aşırı büyüme ve özellik şişmesine rağmen hâlâ oldukça iyi ayakta kalıyor,
    güvenlik ekibi de gerçekten sık sık ilginç şeyler buluyor

    • Çok sayıda Unit 8200 çıkışlı kişi var
    • Fazla gürültü olduğu için biz yalnızca critical seviyeye bakmak üzere osv-scanner ve trivy çalıştıran özel bir pipeline kullanıyoruz
    • Orada değilim ama şirketimizde denediğimizde tamamen zararsız davranışlarda sürekli uyarı veriyor
      ama CLI ile DC sorgulayıp kimlik bilgisi sıfırlamak gibi biraz şüpheli işlerde sessiz kalınca insanın hevesi kaçıyor

  • babeld, push isteğini iletirken dahili isteğin X-Stat başlığına push option'larını koyuyor,
    ve bu değer kullanıcının git push -o ile verdiği rastgele bir dizge
    Ama noktalı virgülleri sanitize etmeden değeri olduğu gibi kopyalayınca,
    ; X-Stat alan ayırıcı olduğu için asıl alandan çıkıp saldırganın yeni alanlar oluşturmasına izin veriyor
    Gerçekten yapılabilecek en basit hatalardan birini olduğu gibi yapmışlar; meyve o kadar alçakta değil de sanki toprağa gömülü gibi

    • Ah, Bobby Tables'ın annesi gerçekten zekiydi

  • Bu, daha istismar edilmeden yakalanmış bir zafiyetken
    BREAKING, unauthorized access, millions of repositories gibi ifadelerle gereksiz korku büyütmeye gerek var mı emin değilim
    https://x.com/wiz_io/status/2049153209982140718

    • Yine de bu ifadeler yanlış da değil
      GitHub, devlet destekli bir saldırgana değil de Wiz'in fuzzing'ine denk geldiği için şanslı sayılır

  • GHES instance'larının %88'inin, 7 hafta önce çıkan kritik güvenlik yamasını hâlâ uygulamamış olması epey ciddi görünüyor
    https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.3

    • GHES fiilen yıllardır neredeyse bakımsız durumda
      Sadece bir patch-level sürümü uygulamak için bile saatlerce kesinti gerekiyor,
      desteklenen bir HA yükseltme yöntemi de yok; bu yüzden düzenli müşteriler bile en güncel sürümü yakından takip etmekte zorlanıyor
      Şikâyet edince herkese GitHub Enterprise Cloud'a geçmeleri söyleniyor,
      ama bugünlerde bunu ne kadar kişinin gönül rahatlığıyla seçeceği de tartışılır
      Yine de GHES'in bir artısı var: github.com'un günlük kesintilerinde durmuyor
    • On-prem müşterilerin önemli bir kısmı GHES'i VPN arkasında tutuyor
      ve muhtemelen operasyonel etkisi düşük bir tarih seçip yükseltme yapmak istiyorlar
      Ama public bir instance ise hemen güncellenmeli
      Haberdeki bilgiler ve herkese açık GitHub Enterprise kaynaklarıyla bile yeniden üretim yöntemi çıkarmak zor görünmüyor
    • Enterprise tarafında düzenli takvim dışında güncelleme yapıp her şeyi bozabilir ve bunun hesabını vermek zorunda kalabilirsiniz,
      ya da plana sadık kalıp bir şey olmamasını umabilirsiniz; çoğu zaman ikincisi seçiliyor
    • Güvenliği çok ciddiye alan ve bu yüzden github.com kullanamayan ortamlarda,
      on-prem bir ürünün yılda bir kez güncellenmesi bile garip karşılanmaz
    • Büyük kurulumlarda asıl mesele yükseltme sürecinin ne kadar kırılgan olduğudur
      Verisi büyük enterprise yazılımlarda ufak bir şey yüzünden kurulumun bozulması ve operasyon ekibinin rollback yapması çok yaygındı
      Eski SharePoint yükseltmeleri resmen zar atmak gibiydi

  • Bu olay da Wiz için büyük bir başarı,
    ve yapay zeka araçlarının RE ile ihlal yollarını bulmayı ne kadar hızlandırdığını gösteren bir dönüm noktası gibi hissettiriyor

    • Bu da kaynağı açık etmemek yapay zekanın daha az açık bulmasını sağlar iddiasını biraz daha zayıflatıyor
      Sonuçta güvenliğin security through obscurity'ye dayanmaması gerektiğine dair bir veri noktası daha eklenmiş oluyor

  • Herkes GitHub'a alternatif bulalım diyor ama o zaman ne kullanacağımız sorusu kalıyor
    GitHub ölçeğinde bir yerde bile artık RCE çıkıyorsa, diğer seçeneklerin daha iyi olduğunu rahatça söylemek zor

    • Thomas Dohmke'nin yeni bir projeyle her şeyi çözeceğine dair şaka da yapılabilir
      https://news.ycombinator.com/item?id=46961345
      https://news.ycombinator.com/item?id=47712656
    • En gerçekçi yanıt galiba self-hosted Forgejo'yu ana forge olarak tutup,
      GitHub'ı yalnızca ücretsiz CI kullandığınız sürece mirror olarak değerlendirmek
      Secret'ları da ayrı bir secret-hosting sağlayıcısına bırakabilirsiniz
    • Biz 6 ay önce GitHub'dan Forgejo self-hosted'a geçtik ve çok iyi çalışıyor
      Forgejo'nun bu kadar hızlı tepki verip GitHub'ın bu kadar yavaşlamış olması hâlâ bana tuhaf geliyor
    • Artık iç kullanım projeleriyle dışa açık projeleri net biçimde ayırıyoruz
      İç projeleri private bir Forgejo instance'ında tutuyoruz, açık projeleri ise GitHub'a koyup Forgejo'ya mirror'luyoruz
      Forgejo'nun pratikte tek binary olması ve yapılandırmasının kolaylığı beni şaşırttı,
      ayrıca tüm dahili servisleri Forgejo'ya bakacak şekilde kurduğumuz için GitHub'dan ayrılmamız gerekirse sürtünme az olur
    • VPN arkasında self-hosted GitLab da gayet iyi bir seçenek
      Hepsi bir arada Docker imajı ve birkaç GitLab runner, küçük ve orta ölçekli ekipler için yeterli
      Gerçekten gerekmiyorsa işi Kubernetes sürümüne kadar karmaşıklaştırmaya gerek yok

  • Kaynak koddan yapay zekanın zafiyet bulması zaten etkileyiciydi,
    bunu binary yürütülebilir dosyalarda da yapabilmesi gerçekten şaşırtıcı
    Bunun hem iyi hem kötü yönde çok büyük bir potansiyeli var
    Ve bir kez daha, veriyi komut gibi ele almamak gerektiği dersi ortaya çıkıyor
    Tüm kullanıcı girdileri sanitize edilmeli

    • Transformer mimarisi aslında çeviri için tasarlanmıştı
      Bu yüzden source-to-source ya da text-to-source işlerinde güçlü olması zaten tanıdık bir hikâyeydi,
      asm sürümlerini anlamaya da uygun çıkması tamamen şok edici sayılmayabilir
      Yine de hâlâ etkileyici

  • Bunun gerçekten istismar edilip edilmediğini belirlemek mümkün olur mu diye merak ediyorum

    • Bana göre bu zafiyet anonim kullanıcılar tarafından da istismar edilebilir görünüyordu
      HTTP/git protocol log'larından istismar olup olmadığını bir ölçüde anlamak mümkün olabilir,
      ama gerçekte neye erişildiği ve bunu kimin yaptığına dair kayıt kalmamış olması da muhtemel
      Çünkü exploit git sunucusunda bağımsız çalıştırılabildiyse, tanımı gereği loglamadan kaçabilmiş olabilir