Alpine Linux GitLab sunucusunu neden sıfırdan kurdu? CVE-2026-97229 ve self-hosted CI için dersler

GitLab'ı kendi sunucunuzda çalıştırıyorsanız son üç haftanın gündemi size tanıdık gelecektir. 12 Ekim'de yamalanan, CVSS 10.0 puanlı CVE-2026-97229 artık sahada aktif olarak istismar ediliyor. ABD'nin siber güvenlik ajansı CISA, açığı Ekim sonunda Bilinen İstismar Edilen Açıklar (KEV) kataloğuna ekledi. Shadowserver da hafta sonu internete açık ve hâlâ yamasız 1.000'den fazla GitLab sunucusu tespit ettiğini duyurdu.

Bu haberi bir “yine kritik açık, yine yama” haberinden ayıran şey ise Alpine Linux'un yayımladığı olay raporu. Alpine, saldırganın büyük ihtimalle başarılı olamadığını düşünüyor. Yine de kod çalıştırıldığını kesin olarak dışlayamadığı için GitLab sunucusunu sıfırdan kurdu. Bu raporun değeri, nadiren bu kadar açık yazılan hataları ve doğru giden adımları birlikte göstermesinde.

Açık tam olarak ne?

GitLab'ın tanımına göre sorun, CI/CD yapılandırmasındaki düzenli ifadeleri (regex) derleyen bileşende bir tam sayı taşması (integer overflow). Özel hazırlanmış bir regex, belirli koşullarda GitLab sunucusunda kod çalıştırılmasına yol açabiliyor.

• Etkilenen sürümler: 19.2.8 öncesi 19.2, 19.3.5 öncesi 19.3 ve 19.4.2 öncesi 19.4 sürümleri (Community ve Enterprise Edition).
• Etkilenmeyenler: GitLab.com ve GitLab Dedicated zaten yamalı. Sorun self-managed kurulumlarda.
• Pratik koşul: GitLab açığı kimlik doğrulaması gerektirmeyen bir açık olarak tanımlıyor. Rapid7'nin yeniden üretim çalışmasına göre ise saldırganın herkese açık bir projede bir branch'e zararlı bir .gitlab-ci.yml gönderebilmesi gerekiyor. Kullanıcıların kendi public projesini açabildiği bir kurulumda sıradan bir hesap bunun için yeterli. Yani kayıt herkese açıksa saldırgan için engel neredeyse yok.

İşin kritik kısmı açığın kaynağı. Hata GitLab'ın kendi kodunda değil, Ruby'nin içindeki regex motoru Onigmo'da. GitLab'ın düzeltmesi aslında Ruby'ye uygulanan bir yama ve bu yama yalnızca GitLab'ın resmi Linux paketlerinde ve container imajlarında geliyor.

Üstelik 21 Ekim'de aynı bileşende ikinci bir kritik açık (CVE-2026-110264) daha yamalandı. Bu açık 7.0'dan beri tüm sürümleri etkiliyor ve 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ile 18.11.13'te düzeltildi. Yani bugün hedeflemeniz gereken sürüm, ilk yamadaki sürümler değil, bu daha yeni sürümler.

Alpine'de ne oldu?

Alpine'in kendi raporundaki zaman çizelgesi kısaca şöyle:

1. 13 Ekim: Ekip GitLab'ı yükseltiyor, ancak yanlışlıkla düzeltmeyi içeren 19.3.5 yerine 19.3.4'ü kuruyor.
2. 20–21 Ekim: Yeni açılmış bir hesap, hazırlanmış CI yapılandırmalarıyla saldırıya geçiyor. GitLab worker'ları sekiz kez çöküyor. Bunların dördünde saldırgan exploit'in bir kısmını ilerletip sonraki adımda takılıyor. Saldırganın Alpine'in GitLab container imajını indirdiği de görülüyor. Bu, exploit'i bu kuruluma göre ayarlamaya çalıştığına işaret ediyor.
3. 22 Ekim: GitLab 19.3.6'ya yükseltiliyor ama sunucu hâlâ açık. Alpine'in imajı GitLab'ın paketlediği Ruby'yi değil standart Ruby'yi kullandığı için düzeltme hiç devreye girmemiş.
4. 26–28 Ekim: Sorun fark ediliyor. Sunucu yalnızca geliştiricilere ve build sunucularına açık bırakılıyor, sıfırdan kuruluyor, tüm parolalar sıfırlanıyor ve GitLab'ın gizli anahtarları değiştiriliyor.

Alpine'in vardığı sonuç dikkat çekici: Kod çalıştırıldığına dair bir kanıt yok, ama saldırı gününe ait bazı loglar eksik olduğu ve dışarıya giden bağlantılar kaydedilmediği için bu ihtimal dışlanamıyor. Saldırı başarılı olsaydı e-postalar, parola hash'leri, 2FA sırları, CI/CD değişkenleri, runner token'ları, entegrasyon kimlik bilgileri ve özel depolar risk altında kalabilirdi.

Doğru giden şey: Anahtarlar GitLab'da değildi

Raporun en öğretici kısmı belki de bu. Alpine'in paket imzalama anahtarları hiçbir zaman GitLab sunucusunda tutulmamış. Ekip, ilgili günlerdeki commit'leri bir geliştiricinin yerel kopyasıyla ve 45 build sunucusunun kayıtlarıyla karşılaştırarak paketlerin ve 21 Ekim'de çıkan sürümlerin değiştirilmediğini GitLab'dan bağımsız olarak doğrulayabildi.

Bir Linux dağıtımının GitLab'ı, binlerce sistemin kurduğu paketlerin üretim hattının parçası. Saldırgan bu hatta kod çalıştırabilseydi, sonuç tek bir sunucunun ele geçirilmesinden çok daha büyük bir tedarik zinciri sorunu olabilirdi. Sizin şirketinizdeki GitLab da küçük ölçekte aynı rolü oynuyor: production'a giden her şey oradan geçiyor ve deploy anahtarları büyük ihtimalle CI değişkenlerinde duruyor.

Geliştiriciler ve DevOps ekipleri için dersler

1. Yama, yalnızca ana paket demek değil

GitLab'ı kaynak koddan, bir dağıtım paketinden ya da kendi imajınızla çalıştırıyorsanız GitLab sürümünü yükseltmek yetmiyor. GitLab'ın 21 Ekim tarihli duyurusu, kendi Ruby'nizi kullanıyorsanız Ruby'yi de 3.3.13, 3.4.12, 4.0.9 veya daha yeni bir sürüme yükseltmeniz gerektiğini açıkça yazıyor. Resmi Omnibus paketi veya resmi imaj kullananlar için Ruby yaması pakete dahil.

# Omnibus kurulumda GitLab ve Ruby sürümünü görmek için
sudo gitlab-rake gitlab:env:info

# Kendi Ruby'nizi kullanıyorsanız
ruby -v

2. Sürüm numarasını iki kez kontrol edin

Alpine'in ilk hatası basit bir sürüm karışıklığıydı. Kritik bir yamada hedef sürümü duyurudan kopyalayıp yükseltme sonrası gerçekten o sürümde olduğunuzu doğrulamak beş dakikanızı alır.

3. Açık kayıt ve public projeler saldırı yüzeyidir

Alpine'e saldıran hesap yeni kaydolmuş bir hesaptı. Şirket içi bir GitLab'da herkese açık kayıt veya herkesin public proje açabilmesi genellikle gerekmiyor. Kayıt için onay mekanizması, e-posta alan adı kısıtlaması ve proje görünürlüğü ayarlarını gözden geçirin.

4. Log yoksa cevap da yok

Alpine'in “dışlayamıyoruz” demesinin sebebi eksik loglar. Raporda kendi dersleri olarak GitLab sunucusundan dışarı çıkan bağlantıları ve veritabanı bağlantılarını kaydetmek ve logları 14 günden uzun saklamak var. GitLab da self-managed kurulumlar için tehdit tespit kuralları yayımladı. Bunlardan biri doğrudan Onigmo kaynaklı worker çökmelerini hedefliyor. Son haftalarda açıklanamayan worker çökmeleri gördüyseniz bunu ciddiye alın.

5. Sırları CI sunucusunun dışında tasarlayın

İmza anahtarlarını ve en kritik kimlik bilgilerini CI sunucusundan ayrı tutmak, Alpine'i en kötü senaryodan kurtaran karardı. Mümkünse kısa ömürlü kimlik bilgileri kullanın. Yamayı geç uyguladıysanız runner token'larını, CI değişkenlerindeki anahtarları ve entegrasyon token'larını yenilemeyi düşünün.

Sonuç

CVE-2026-97229 teknik olarak bir regex motoru hatası. Ama asıl hikâye, self-hosted bir CI/CD sunucusunun ne kadar değerli bir hedef olduğu ve yamanın sanıldığından daha fazla parçadan oluştuğu. Alpine'in raporunu kendi ekibinizle bir tatbikat senaryosu olarak okumanızı öneririm: Aynı saldırı bizim GitLab'ımıza gelseydi kod çalıştırılıp çalıştırılmadığını söyleyebilir miydik? Bu sorunun cevabı “hayır” ise, yamadan sonraki ilk iş log ve sır yönetimi olmalı.