GitLab Kritik Güvenlik Açığı: CVSS 10.0 RCE İçin Ne Yapmalı?

GitLab kritik güvenlik açığı, kimlik doğrulaması olmadan sunucuda kod çalıştırılmasına izin veriyor ve CVSS ölçeğinde en yüksek puan olan 10,0'ı taşıyor. GitLab, açığı 21 Ekim 2026'da yamaladı. Yalnızca self-managed (kendi sunucunuzda çalışan) kurulumlar risk altında; GitLab.com zaten güncel. Kendi GitLab'ını işleten bir ekipseniz sürümünüzü bugün kontrol etmelisiniz.

Kısaca:

• Açık, düzenli ifade (regex) derleyicisindeki bir integer overflow hatasından kaynaklanıyor ve CVSS 10,0 olarak derecelendirildi.
• Kaynaklara göre etkilenen sürümler 7.0'a kadar uzanıyor; yani yaklaşık 12 yıllık sürüm geçmişi kapsanıyor.
• Geçici çözüm yok; tek çare 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 veya 18.11.13 sürümlerinden birine yükseltmek.
• GitLab istismar gözlemlemediğini söylüyor, ancak bu durum her an değişebilir.

GitLab kritik güvenlik açığı tam olarak ne?

Sorunun kökünde bir düzenli ifade derleyicisi var. Ruby'nin yerleşik regex motoru Onigmo'da bir integer overflow hatası bulunuyor. GitLab bu motoru paketlerinin içinde gömülü ve yamalı olarak dağıtıyor. Bu yüzden hata, sunucunuzdaki ayrı bir bileşen olarak değil GitLab'ın kendisinin bir parçası olarak karşınıza çıkıyor.

Integer overflow, bir sayının tutulabileceği sınırı aşması ve beklenmedik biçimde "taşması" demek. Bu tür hatalar bellekte yanlış alan ayrılmasına yol açabilir. Saldırgan bunu uygun biçimde tetiklerse, kimlik doğrulamasına gerek kalmadan sunucuda kendi kodunu çalıştırabilir. CVSS 10,0 puanı da tam bu yüzden verilmiş: saldırı uzaktan yapılabiliyor, giriş gerektirmiyor ve etkisi tam sistem ele geçirme düzeyinde.

CVE numarası neden iki farklı yazılıyor?

Kaynaklar arasında bir tutarsızlık var. The Hacker News ve Mallory, CVE-2026-110264 numarasını kullanıyor. SOC Prime, Help Net Security ve diğer bazı kaynaklar ise 12 Ekim'de duyurulan CVE-2026-97229'u anıyor.

Biz 21 Ekim sürümüne ait resmi GitLab duyurusuna ulaşamadık, bu yüzden hangi numaranın doğru olduğunu kesin söyleyemiyoruz. Pratikte fark şu: sistemlerinizi taramak ya da kayıt aramak için her iki numarayı da kullanın. Asıl işlem değişmiyor, hangi numarayla anılırsa anılsın düzeltilmiş sürüme geçmeniz gerekiyor. Kesin eşleşme için GitLab'ın kendi güvenlik duyurusuna bakmanızı öneririz.

Hangi sürümler etkileniyor ve hangi sürüme geçmeli?

Mallory'nin aktardığına göre etkilenen sürümler 7.0'a kadar geriye gidiyor. GitLab'ın yayımladığı düzeltilmiş sürümler şunlar:

18.11.13, 19.0.10, 19.1.9 ve 19.2.9, GitLab'ın olağan sürüm takvimi dışında yayımladığı geriye dönük yamalar. Yani eski bir hatta takılı kaldıysanız bile sizin için ayrı bir yama çıkarılmış. Bu listenin dışında kalan, çok eski bir sürüm kullanıyorsanız önce desteklenen bir hatta yükseltme yapmanız gerekir.

Kimler işlem yapmalı?

GitLab.com ve uygun GitLab Dedicated kiracıları zaten yamalı durumda. Onlar adına yapılacak bir şey yok. İşlem gerektiren grup, GitLab'ı kendi altyapısında çalıştıran ekipler: kendi sunucusunda, kendi veri merkezinde ya da kendi bulut hesabında GitLab işletenler.

12 Ekim güvenlik güncellemesini uygulamış olmanız sizi korumuyor. Mallory'nin aktardığına göre bu güncellemeyi yapanların da yukarıdaki sürümlere yükseltmesi gerekiyor.

Geçici çözüm var mı?

Hayır, kaynaklarda bir geçici çözüm ya da hafifletme önlemi belirtilmiyor. Güvenlik duvarıyla erişimi kısıtlamak riski azaltabilir, ancak bu bir çözüm değil; yalnızca yükseltme planlanana kadar saldırı yüzeyini daraltmanın bir yolu. GitLab'ınız internete açıksa önce bunu gözden geçirin, ardından yükseltmeyi öne alın.

Açık istismar ediliyor mu?

GitLab, bu açığın istismar edildiğini gözlemlemediğini bildiriyor. 22 Ekim itibarıyla açık, CISA'nın bilinen istismar edilen açıklar kataloğunda (KEV) da yer almıyor. Bu iyi haber, ama rahatlamak için bir gerekçe değil. Kritik ve kimlik doğrulaması gerektirmeyen açıklar için yama yayımlandıktan sonra istismar kodunun ortaya çıkması genellikle günler içinde gerçekleşir. Yama farkından saldırı üretmek mümkün olduğundan, yama yayımlandığı an bir zaman sayacı da başlamış olur.

GitLab ayrıca olası istismar girişimlerini yakalamak için iki tespit kuralı yayımladı. Güvenlik izleme altyapınız varsa bu kuralları eklemek, yükseltme tamamlanana kadar ek bir güvence sağlar.

Açık nasıl bulundu?

CVE-2026-97229 kaydına göre açık, HackerOne bug bounty programı üzerinden bildirilmiş ve kredi araştırmacı joaxcar'a verilmiş. Bu, sorumlu bildirim sürecinin işlediğini gösteriyor: açık saldırganlardan önce üretici tarafından öğrenildi ve yama hazır olduktan sonra duyuruldu. Yukarıda belirttiğimiz numara belirsizliği nedeniyle bu bilginin hangi kayda ait olduğunu da not düşmek gerekir.

Bu açık tek mi? Daha önce neler yaşandı?

Hayır. Ağustos 2026'da GitLab'ın GraphQL katmanında da ayrı bir kritik açık yamalanmıştı. Kendi GitLab'ını işletmek, bu tür duyuruları düzenli takip etmeyi gerektiriyor. Kod deposu, CI/CD hatları ve gizli anahtarlar aynı yerde durduğu için bir GitLab sunucusunun ele geçirilmesi yalnızca o sunucuyu değil, bağlı olduğu tüm projeleri riske atıyor. Bu yüzden benzer bir PHP güvenlik açığı için yaptığımız gibi, yama sürecini bir "olursa yaparız" işi olarak değil, takvimli bir iş olarak ele almanızı öneririz.

Sıkça sorulan sorular

GitLab.com kullanıyorsam bir şey yapmam gerekiyor mu?

Hayır. GitLab.com ve uygun GitLab Dedicated kiracıları zaten yamalı. Yalnızca kendi sunucusunda GitLab çalıştıranların yükseltme yapması gerekiyor.

12 Ekim güncellemesini yaptım, yeterli mi?

Hayır. 12 Ekim güvenlik güncellemesini uygulamış olsanız bile 21 Ekim'de yayımlanan sürümlerden birine yükseltmeniz gerekiyor.

Yükseltme yapamıyorsam ne yapmalıyım?

Resmi bir geçici çözüm yok. Yükseltme planlanana kadar sunucunuzun internete erişimini güvenlik duvarıyla sınırlayın, GitLab'ın yayımladığı iki tespit kuralını izleme sisteminize ekleyin ve yükseltmeyi mümkün olan en kısa sürede yapın.

Sunucumun saldırıya uğrayıp uğramadığını nasıl anlarım?

GitLab'ın yayımladığı tespit kuralları tam bu amaçla hazırlandı. Bunun yanında beklenmedik süreçler, yeni oluşturulmuş yönetici hesapları ve olağandışı giden bağlantılar için sunucu günlüklerini inceleyin. Şüpheli bir bulgu varsa kimlik bilgilerini ve deponuzdaki gizli anahtarları yenilemeyi düşünün.

Sonuç

Kritik açıklarda en büyük risk, yama çıktıktan sonra "sonra bakarız" demektir. Self-managed bir GitLab işletiyorsanız sürümünüzü kontrol edin, yukarıdaki tablodan size uygun düzeltilmiş sürümü seçin ve yükseltmeyi bu hafta içinde tamamlayın. Kendi altyapınızda yama yönetimi, yedekleme ve izleme süreçlerini kurmak ya da bu yükü devretmek istiyorsanız EngerekTech ekibi olarak bu konuda destek verebiliriz.

Kaynaklar