GitLab CVE-2026-97229 Saldırıda: CISA KEV Listesinde, Sorun Ruby Onigmo’da, Yalnız GitLab’ı Yükseltmek Yetmeyebilir

Ne oldu? (CVE-2026-97229 timeline)

GitLab 12 Ekim 2026'da 19.4.2, 19.3.5 ve 19.2.8 sürümlerini yayımladı. Bu yama paketinde 24 güvenlik açığı vardı; en ağırı CVE-2026-97229 idi. GitLab'ın tanımıyla açık, "CI/CD düzenli ifade derleyicisinde tamsayı taşması" (integer overflow). Belirli koşullarda kimliği doğrulanmamış bir kullanıcı, CI yapılandırmasına koyduğu özel bir regex ile GitLab sunucusunda kod çalıştırabiliyor.

Sonraki iki hafta içinde olaylar hızlandı:

• 23 Ekim: Ruby ekibi 4.0.9, 3.4.12 ve 3.3.13 sürümlerini çıkardı. Duyuruda bu sürümlerin GitLab'ın dört CVE'sine (CVE-2026-89078, CVE-2026-93577, CVE-2026-97229, CVE-2026-110264) yol açan Onigmo hatalarını düzelttiği yazıyor.
• 21 Ekim civarı: GitLab, ikinci bir CVSS 10.0 açığı olan CVE-2026-110264'ü de kapatan yeni yama sürümlerini yayımladı. 12 Ekim'de yükseltenlerin tekrar yükseltmesi gerekiyor.
• 28 Ekim: Alpine Linux, kendi GitLab sunucusunun bu açıkla hedef alındığını, GitLab'ı yükseltmesine rağmen sunucudaki Ruby'nin eski kaldığını ve sunucuyu yeniden kurduğunu duyurdu (ikincil kaynaklara göre).
• 29 Ekim: CISA, CVE-2026-97229'u KEV kataloğuna ekledi. Aynı gün listeye Cisco Secure Firewall ASA ve FTD yazılımındaki bir açık da girdi.

Neden sorun Ruby'de? (Onigmo regex engine)

Ruby, düzenli ifadeleri Onigmo adlı motorla derliyor. Açıkların ortak noktası, derleme sırasında tutulan sayaçların taşması. Örneğin CVE-2026-110264'te tekrar eden grupların kimlikleri işaretli 16 bitlik bir alanda tutuluyor; 32.767'den fazla tekrar içeren bir desen sayacı eksi değere çeviriyor ve bellek dışına yazmaya yol açıyor. GitLab, kullanıcıların CI dosyalarında yazdığı regex'leri sunucuda derlediği için saldırgana bu kapıyı açmış oluyor.

Bunun pratik sonucu şu: GitLab'ın resmî Linux paketleri (Omnibus) ve resmî konteyner imajları kendi Ruby'sini getiriyor, onlarda GitLab'ı yükseltmek yeterli. Ama GitLab'ı kaynaktan kuranlar ya da Ruby'yi işletim sisteminin paketinden kullanan imajlar için GitLab yükseltmesi Ruby'ye dokunmuyor. Alpine olayında yaşanan tam olarak buydu.

Ruby ekibi şimdilik bu düzeltmeler için kendi CVE numarasını almadığını belirtiyor. Yalnız Ruby CVE'lerine bakan tarayıcılar eski Ruby'yi "temiz" gösterebilir.

Hangi sürüme geçmeli? (Fixed versions)

GitLab.com ve GitLab Dedicated müşterileri için bir şey yapmaya gerek yok; ikisi de yamalandı. Tek düğümlü kurulumlarda 12 Ekim yaması veritabanı göçü içerdiği için kısa bir kesinti bekleyin.

Sunucunuzda nasıl kontrol edersiniz?

Önce GitLab sürümünü, sonra GitLab'ın gerçekte kullandığı Ruby'yi görün. Omnibus kurulumda:

sudo gitlab-rake gitlab:env:info | grep -E "GitLab information|Version|Ruby Version"
/opt/gitlab/embedded/bin/ruby -v

Kaynaktan kurulumda ya da kendi imajınızda ise uygulamanın çalıştığı kullanıcıyla:

which ruby
ruby -v
bundle exec ruby -v

Çıktıdaki Ruby sürümü yukarıdaki tablonun altındaysa GitLab sürümü ne olursa olsun açık devam ediyor demektir. Yükseltmeden sonra Puma ve Sidekiq süreçlerini yeniden başlatmayı unutmayın; eski kütüphaneyi bellekte tutan süreç açığı taşımaya devam eder.

sudo gitlab-ctl restart
sudo gitlab-ctl status

Hemen yükseltemeyenler için (Workarounds)

GitLab, yükseltme dışında bir geçici çözüm önermiyor. Güvenlik araştırmacılarının önerdiği ve yalnız bilinen saldırı yolunu zorlaştıran adımlar şunlar:

• Kayıt olmayı kapatın ya da yönetici onayına bağlayın. Saldırı yolu, yeni açılmış bir hesabın herkese açık bir projeye CI dosyası koymasıyla başlıyor.
• Güvenilmeyen kullanıcıların herkese açık proje oluşturmasını ve bu projelere yazmasını engelleyin.
• Anonim kullanıcıların herkese açık projelere erişimini kısıtlayın.
• GitLab'ı yalnız VPN ya da güvenilir IP adreslerinden erişilir hale getirin.

Bunlar kalıcı çözüm değil. Bilinen yolu kapatmak, başka bir yolu kapatmıyor.

İhlal belirtileri (Indicators)

GitLab, self-managed kurulumlar için altı tespit kuralı yayımladı; adları sorunun nerede iz bıraktığını da gösteriyor: Onigmo yerel işçi çökmesi, GraphQL CI lint'e düşmanca regex, aşırı uzun ASCII dışı CI regex yolu, CI regex korumasının reddi, CI lint işçi çökmesi ve CI lint'e art arda betikli istemci hatası. Kendi günlüklerinizde bakılacak yerler:

• Yeni açılmış hesapların kısa sürede CI yapılandırması göndermesi ya da CI lint uç noktasını çağırması.
• Puma işçilerinin açıklanamayan çökmeleri ve yeniden başlamaları.
• GitLab kullanıcısının (git) altından başlayan beklenmedik kabuk süreçleri, yeni SSH anahtarları, yeni yönetici hesapları.

Başarılı bir saldırının çökme ya da web günlüğü izi bırakmayabileceği belirtiliyor. Şüphe varsa sunucuyu ele geçirilmiş sayın: erişim jetonlarını, CI değişkenlerindeki sırları, runner kayıt jetonlarını ve GitLab'ın gizli anahtarlarını yenileyin. Kendi Git sunucusunu barındıran ekiplere Alesta WEB olarak önerimiz, GitLab'ı internete açık tutmak zorunda değilseniz bu fırsatla erişimi kısıtlamanız.

Sık sorulan sorular

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

Hayır. GitLab.com ve GitLab Dedicated yamalandı. Yalnız kendi sunucunuzdaki (self-managed) kurulumlar etkileniyor.

Ruby on Rails uygulamam da etkilenir mi?

Uygulamanız kullanıcıdan gelen metni Regexp.new, Regexp.union ya da değişken içeren regex ile derliyorsa evet. Yalnız geliştiricinin yazdığı sabit desenleri kullanan uygulamalar risk altında değil. Ruby'yi yine de güncelleyin.

Regexp.timeout ayarı korur mu?

Hayır. Sorun eşleştirmede değil, derlemede; zaman aşımı devreye girmeden bellek bozuluyor.

Docker imajımı nasıl kontrol ederim?

Konteynerin içinde ruby -v çalıştırın. GitLab'ın resmî imajını kullanıyorsanız GitLab sürümünü yükseltmek yeterli; kendi imajınızı Ruby paketiyle kuruyorsanız imajı yeniden derleyin.

İlgili yazılar: GitLab 19.5 yenilikleri · PHP2Shell açığı nasıl kapatılır · Web yazılım hizmetleri · İletişim

Kapak fotoğrafı: Victorgrigas / Wikimedia Commons (CC BY-SA 3.0)