Şunu fark ettim: Açık konuşayım, bu hafta sabah kahvemi içerken GitHub Security Blog’da çıkan yazıyı görünce bardağı masaya bıraktım. git push komutuyla, hem de tek satırda, GitHub sunucularında uzaktan kod çalıştırmak… Yanı bizim her gün yüzlerce kez yaptığımız o masum komutla. Hayda.
4 Mart 2026’da Wiz ekibinden bir araştırmacı, GitHub’ın Bug Bounty programına bir rapor düşürmüş. Konu basit gıbı duruyor, ama sonuçları hiç öyle değil: github.com, GitHub Enterprise Cloud (Data Residency ve EMU dahil) ve GitHub Enterprise Server’ı etkileyen can alıcı seviyede bir Remote Code Execution açığı var ortada. CVE numarası da CVE-2026-3854. Bir bakıma, peki neden?
GitHub tarafının tepkisi gerçekten takdire yakınmış — raporu aldıktan iki saatten az bir sürede doğrulamışlar, fix’i deploy etmişler, sonra da forensic analizi başlatmışlar; yanı işin peşini bırakmamışlar. Sonuç? Gerçek dünyada sömürülmemiş. Ama durun bir saniye — mesele bizim tarafta bitmiyor (en azından benim deneyimim böyle). Bilhassa GitHub Enterprise Server kullanan kurumsal müşteriler için iş daha yeni başlıyor (en azından benim deneyimim böyle)
Evet, doğru duydunuz.
Olayın Özeti: Tek Satırlık git push ile RCE
Sade anlatayım. Repoya push yetkisi olan herhangi biri — kendi açtığı repo bile ölür — özel hazırlanmış bir push option ile, GitHub’ın o push’u işleyen tarafında rastgele komut çalıştırabiliyordu. Tek komut, hepsi bu. Multi-stage exploit yok, zincir yok, gösterişli bir şey de yok.
İşin aslı biraz tuhaf. Siz git push yaptığınızda GitHub içeride birkaç servisi ayağa kaldırıyor, sonra push’a ait metadata’yı (repo tipi, hangı ortamda işlenecek, benzeri şeyler) bu servisler arasında bir internal protokol üzerinden dolaştırıyor. Kritik nokta şu: kullanıcının verdiği git push --push-option=... değeri yeterince temizlenmeden bu metadata’nın içine gömülüyormuş.
Ve işler burada ilginçleşiyor.
Metadata formatı bir delimiter karakter kullanıyor. Evet, mesele tam burada kopuyor. Aynı karakter kullanıcı input’unda da geçebiliyor; yanı saldırgan push option değerine o delimiter’ı koyunca metadata’ya yeni alanlar enjekte edebiliyor, downstream servisler de bunları “güvenilir iç değer” sanıp yutuyor.
“Birkaç enjekte edilmiş değeri zincirleyerek araştırmacılar; push’un işlendiği ortamı override edebildiklerini, hook execution’ı kısıtlayan sandbox korumalarını bypass edebildiklerini ve sonunda sunucuda komut çalıştırabildiklerini gösterdi.” — GitHub Security Blog
Tanıdık Bir Kalıp: Internal Protocol Injection
Bi saniye — Buna bakınca, özellikle 20 küsur yıllık sistem yönetimi geçmişimle söyleyeyim, insanın aklına direkt eski tanıdık numaralar geliyor. Hani SQL injection’ın kuzeni gıbı düşünün; format string var, içinde delimiter olarak kullanılan bir karakter var. Dışarıdan gelen veriyi o formata yapıştırıyorsunuz. Klasik ama can sıkıcı, çünkü bu sefer mesele HTTP request değil, içerde dönen mikroservis trafiği (ben de ilk duyduğumda şaşırmıştım)
2018’de bir e-ticaret müşterimizde benzer bir şeye denk gelmiştim. Order processing sisteminde alanları pipe karakteri (|) ile ayırıyorlardı; müşteri adres alanına pipe yazınca downstream fraud detection servisi yanlış değerleri okumaya başladı (RCE değildi tabii), ama mantık birebir aynıydı: “iç” dediğimiz protokol dış input ile beslenince artık pek iç sayılmıyor — bence çok yerinde bir karar —
Neyse, çok dağıtmadan söyleyeyim; burada güven sınırı yanlış yerde çizilmişti. Neyse, peki neden? Çünkü geliştirici gözünde “bu veri zaten bizim sistemden geliyor” hissi var ya, işte en pahalı hata çoğu zaman orada başlıyor.
GitHub Nasıl Tepki Verdi: iki Saatte Patch
İşin en ilginç tarafı bence burası. Zaman çizelgesi kabaca şöyle ilerliyor:
| Saat (UTC) | Olay |
|---|---|
| 4 Mart, ~5:00 PM | Bug Bounty raporu Wiz’den geldi |
| ~5:40 PM | İçeride zafiyet reproduce edildi (40 dk) |
| 5:45 PM | Root cause tespit edildi |
| 7:00 PM | github.com’a fix deploy edildi |
| Sonrası | Forensic analiz: exploitation yok |
İki saatte bug bounty raporundan production fix’e gitmek… Bak şimdi, bu hız baya dikkat çekiyor. Logosoft’taki kurumsal müşterilerimde bu iş çoğu zaman günler sürüyor, bazen de haftalara yayılıyor; tabii GitHub’ın altyapısı. Işleyişi ayrı bir dünya, ama yine de burada elimizde sağlam bir kıyas noktası var.
Türkiye Açısından: Bu Tempo Bizde Mümkün mü?
Açık konuşayım, gördüğüm tablo pek parlak değil. Türkiye’deki şirketlerin büyük kısmı böyle bir incident response hızına sahip değil; mesele sadece teknik ekiplerin yeteneği de değil, karar zinciri uzuyor, change management komiteleri devreye giriyor, “önce CAB toplantısı yapalım” refleksi hemen geliyor… Bir bankada P1 fix deploy etmek bazen 48 saati bulabiliyor, hatta iş biraz karışırsa daha da sarkıyor.
Bence işin aslı şu: Sıfır gün açıklarına hızlı cevap verebilmek için pre-approved emergency patching süreci lazım. CAB’i tamamen çöpe atmadan, ama izlenebilir ve geri alınabilir bir yol açarak ilerlemek gerekiyor; hani şu kriz anında herkesin birbirine bakıp kaldığı durumları azaltan model var ya, işte o. Bunu kurabilen ekipler bir adım öne çıkıyor.
Evet.
GitHub Enterprise Server Müşterileri İçin Açıl Aksiyon
github.com tarafında iş zaten otomatik çözülüyor. Ama kendi datacenter’ınızda GHES çalıştırıyorsanız, top sizde. Yamalı sürümler de şunlar:
- 3.14.25 veya sonrası
- 3.15.20 veya sonrası
- 3.16.16 veya sonrası
- 3.17.13 veya sonrası
- 3.18.8 veya sonrası
- 3.19.4 veya sonrası
- 3.20.0 veya sonrası
Şahsen, Eğer kullandığınız sürüm bu eşiklerin altındaysa, yanı evet, çoğu kurumda denk gelme ihtimali var, push trafiğini biraz kısmayı düşünün ya da direkt yamaya geçin; açık konuşayım, burada fazla oyalanmak pek iyi fikir değil.
Peki kendi GHES’inizde neye bakacaksınız?
Şunu söyleyeyim, Geçen yıl bir kamu kuruluşu projesinde GHES denetlemesi yapmıştık; orada gördüğüm şey şu öldü: versiyon tek başına yetmiyor, çünkü bazen sistem güncel görünüyor. Kenarda köşede kalan bir entegrasyon işi bozabiliyor, o yüzden aşağıdaki kontrolleri sırayla yapmak daha mantıklı geliyor.
Evet, doğru duydunuz.
- Versiyon kontrolü: Admin Center’dan mevcut sürümü teyit et.
/setup/api/maintenanceendpoint’i de işe yarar. - Push log analizi: Son 90 günün push event’lerinde anomali var mı? Bilhassa
--push-optioniçeren push’lara bakın; çoğu organizasyon bunu aktif kullanmıyor zaten, o yüzden bir anda artış görürseniz ben olsam kaşımı kaldırırım. - Hook execution log’ları: Server-side hook’ların çalıştırdığı komutları gözden geçir. Beklenmedik process spawn’ları var mı?
- Network egress: GHES sunucusundan dışarı çıkan trafiği kontrol et. RCE tarafında tipik tabloyu genelde bilinmedik IP’lere giden outbound connection olarak görüyorsunuz.
- Yamayı vur: Maintenance window planla, snapshot al ve yükselt; şey, lafı gevelemeden söyleyeyim, bu adımı ertelemek yerine takvime koymak daha iyi duruyor. — ciddi fark yaratıyor
Bakın, neyse, çok dağıtmadan toparlayayım: sürümünüz eskiyse önce riski kısın, sonra test edin, en son da yamayı uygulayın.
Evet.
Denediniz mi hiç?
Push Option Nedir, Neden Tehlikeli Olabiliyor?
Vallahi, Bir saniye geri gidelim. git push options dediğimiz şey, git’in bilerek koyduğu bir özellik; yanı git push --push-option=key=value ile push sırasında server tarafına key-value bilgi yolluyorsunuz, hani CI/CD tetiklemek, deployment flag vermek ya da MR/PR otomatik açmak gıbı işlerde baya iş görüyor.
Mesela GitLab tarafında bu iş çok sık kullanılıyor: git push -o ci.skip deyince o push için CI’ı atlayabiliyorsunuz. GitHub’da da benzer bir kullanım var, ama orada detaylar biraz farklı ilerliyor.
# Normal kullanım
git push origin main -o deploy-environment=staging
# Saldırının prensibi (gerçek payload değil, illüstratif)
git push origin main -o "key=value<DELIMITER>internal-field=malicious"
Yanı, İşin asıl kritik tarafı şu: Push option’ın kendisi problem değil. Problem, kullanıcıdan gelen input’un internal serialization formatına escape edilmeden gömülmesi; açık konuşayım, bu bildiğiniz klasik bir input validation ve ayrıştırma hatası, üstelik ilk bakışta masum duruyor ama sonra pat diye başka yere sıçrıyor.
Defense in Depth: Tek Kontrol Yetmiyor
Saldırının garip ama öğretici tarafı burada çıkıyor. Sadece input sanitization yetmiyor; aynı zamanda sandbox mantığını da dolanabiliyor,. Ortamı override edip hook execution kısıtlarını es geçebiliyor, bu yüzden katmanlı savunma kağıt üstünde hoş dursa da katmanlar birbirinden bağımsız çalışmıyorsa tek bir injection bütün zinciri bozabiliyor — bence çok yerinde bir karar —
Ben kendi danışmanlık projelerinde, AZ-500 hazırlığında da defalarca konuştuğum üzere, hep aynı yere dönüyorum: “Trust boundaries”. Her servis kendine gelen veriyi asla güvenilir saymamalı. Upstream servis “iç” olsa bile. Çünkü o iç servis de başka bir yerden besleniyor — ve işin üçü çoğu zaman dış dünyaya kadar gidiyor. .NET 10’da API Versioning ve OpenAPI: Pratik Entegrasyon yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Copilot Student’tan GPT-5.3-Codex Çıktı: Ne Anlama Geliyor? yazımıza da göz atmanızı tavsiye ederim.
Kısa bir not düşeyim buraya.
Kurumsal Çıkarımlar: Ne Öğrenmeliyiz?
Yanı, Bu olaya bakıp sadece “GHES yamasını vur” demek, işin kolayına kaçmak ölür. Bence asıl mesele başka yerde duruyor, yanı biraz daha derinde; yoksa yüzeyde kalan herkes aynı hatayı tekrar ediyor.
1. Bug Bounty Programları Gerçekten İşe Yarıyor
Wiz ekibi bunu bulup sorumlu şekilde bildirmeseydi, başkası bulur ve sömürürdü, bu kadar net. Türkiye’de bug bounty kültürü hâlâ tam oturmadı; — ki bu tartışılır — BTK’nın yaptığı işler var, bazı bankalar kendi programlarını açtı,. Hâlâ çoğu kurum “responsibly disclose” yapan araştırmacıya şüpheyle bakıyor, hatta bazen işi tehdit boyutuna taşıyor. Açık konuşayım, bu kafa değişmeden güvenlik tarafında rahat nefes almak zor.
Evet.
2. Push Trafiği Audit Edilmeli
Kurumsal müşterilerimde audit log denince akla çoğunlukla “kim repoya erişti” geliyor, gerisi biraz unutuluyor. Ama push içeriği ve parametreleri çoğu yerde toplanmıyor, işte sorun da burada çıkıyor; bu olay tam olarak push parametrelerinden patladı. Siz ne dersiniz? Axios npm Saldırısı: Azure Pipelines Kullananlar İçin Rehber yazımda da dediğim gıbı, supply chain güvenliği artık kodun yanında commit metadata’sı‘nı da izlemeyi gerektiriyor (yanı sadece dosya değil, o dosyanın nasıl geldiği de önemli). Bu konuyla ilgili Copilot Cloud Agent %20 Daha Hızlı: Custom Image Etkisi yazımıza da göz atmanızı tavsiye ederim.
Peki neden?
3. SaaS vs Self-Hosted: Risk Profili Farkı
Bu olay bir kez daha şunu gösterdi: github.com kullananlar için fix saatler içinde geldi ve kimse yerinden kalkmadı. GHES tarafında işe yamayı siz vuruyorsunuz; compliance yüzünden self-hosted gitmek bazen mecburi oluyor, önü anlıyorum, (evet, doğru duydunuz). Operasyonel yükü hafife alırsanız incident anında tokadı yersiniz. Şey, işin can sıkıcı kısmı da bu zaten (buna dikkat edin)
Eğer küçük bir startup iseniz, GHES’i merkezde tutup üstüne security ekibi kurmak bana pek mantıklı gelmiyor; github.com Enterprise çoğu zaman yeterli oluyor. Eğer büyük bir kurumsal yapıdaysanız. Regulatory zorunluluklar varsa, Yeni GitHub PR Dashboard: Artık Varsayılan Geliyor gıbı yeniliklerin GHES’e gecikmeli geleceğini de hesaba katın — yanı hem daha geç özellik alıyorsunuz hem de üstüne daha çok operasyonel iş çıkıyor. Tam da öyle.
4. “Hızlı Yama” Politikası Şart
Bir önceki bölümde değindim ama burada tekrar söyleyeyim; critical CVE’ler için CAB-bypass eden, ama yine de denetlenebilen. Geri alınabilen bir emergency patching prosedürünüz olsun. Yoksa böyle bir olayda 72 saat bekleyen kurum, açık konuşayım, riski fiilen kendi üstüne almış oluyor — itiraf edeyim, beklentimin üstündeydi —. Bu kadar mı? Değil tabii.
Maliyet Perspektifi: Bu Tıp Açıklara Hazırlık Ne Kadar Tutar?
FinOps tarafına da bir bakalım, çünkü işin parasal kısmı bazen teknik kısımdan daha çabuk can sıkıyor. Bir GHES deployment’ında “hızlı patching kabiliyeti” için birkaç şey gerekiyor,. Öyle tek tuşla çözülen bir mevzu değil.
- Test/staging ortamı: Production GHES’inizin küçük bir kopyası gıbı düşünün. Aylık ek maliyet, Azure’da ortalama bir VM ile storage’ı yan yana koyunca 200-400 USD bandına oturuyor.
- Otomatik snapshot/backup pipeline: Azure Backup ya da benzeri bir yapı iş görüyor. Volume’a göre değişiyor ama kurumsal ölçekte aylık 100-300 USD civarı gidiyor.
- On-call rotasyonu: Asıl para burada çıkıyor. İnsan kaynağı, mesai, uykusuzluk… işte hesabı zorlayan kalem bu.
TL bazında bakınca tablo biraz daha netleşiyor. Küçük-orta ölçekli bir kurum için (söylemesi ayıp) aylık 15-25 bin TL civarında bir altyapı maliyeti çıkabiliyor; kötü mü, değil. Ama durun, asıl kıyas o değil — tek bir critical incident’in faturası bunun yanında çoğu zaman çok daha ağır kalıyor (şaşırtıcı ama gerçek)
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Sıkça Sorulan Sorular
CVE-2026-3854 benim github.com hesabımı etkiledi mi?
github.com’a fix 4 Mart akşamı deploy edildi. GitHub’ın forensic analizine göre aslında gerçek dünyada hiç sömürülmemiş — yanı SaaS GitHub kullanıyorsanız sizin için kapanmış bir konu, ek bir şey yapmanıza gerek yok.
GHES kullanıyorum ama push option özelliğini hiç kullanmıyoruz, yine de yamayı vurmam gerekir mi?
Net bir şekilde evet. Hani “biz kullanmıyoruz” demek sızı korumaya yetmiyor — saldırgan bu komutu git protokolü seviyesinde gönderebiliyor, sizin feature’ı aktif kullanıp kullanmadığınızla ilgilenmiyor. Yetkili bir kullanıcı, kendi açtığı repoda bile bunu yollayabilir. Açıkçası yamayı bekletmemek lazım.
Push option’ları toptan engellesem yeterli ölür mu?
Aslında, Geçici bir mitigation olarak işe yarayabilir. Ama yama yine de şart. Üstelik bazı CI/CD entegrasyonlarınız push option’a bağlı çalışıyorsa onlar da kırılır — yanı bence ekstra zahmete değmez, direkt yamayı vurun.
Bu açık nasıl tespit edilebilirdi, kendi kodumuzda benzer pattern var mı diye nasıl bakarım?
Tecrübeme göre ilk bakılacak yer şurası: internal serialization formatlarınızda kullandığınız delimiter karakterleri — mesela pipe, null byte, özel ayraçlar — bunlar kullanıcı input’unda düzgünce escape ediliyor mu? Semgrep ya da CodeQL gıbı statik analiz araçları bu tıp pattern’lar için kural yazmaya oldukça uygun. En çok da String.format, string concat veya custom serialization kullandığınız yerleri taramak mantıklı bir başlangıç noktası (ben de ilk duyduğumda şaşırmıştım)
Bug bounty programı kurmak Türkiye’de pratik mi?
Daha açık söyleyeyim, bi saniye — HackerOne, Intigriti gıbı platformlar Türkiye’den de kullanılabiliyor. Asıl zorluk teknik değil, organizasyonel aslında — yanı VDP (Vulnerability Disclosure Policy) yayınlamak, yasal çerçeveyi oturtmak. Raporlara hızlı dönecek bir ekip oluşturmak. Bence küçük başlamak en mantıklısı; sadece bir VDP yayınlamak bile büyük bir adım sayılıyor.
Kaynaklar ve İleri Okuma
GitHub Security Blog: Securing the git push pipeline (Alexis Wales)
Neyse, şunu fark ettim: GitHub Security Advisories — CVE-2026-3854
İtiraf edeyim, GitHub Enterprise Server Release Notes
Git Resmî Dokümantasyonu: –push-option
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
