Şirketiniz GitLab'ı kendi sunucusunda çalıştırıyorsa bugün güncelleyin. GitLab, 12 Ekim 2026 tarihinde 24 güvenlik açığını gideren kritik bir güvenlik yaması yayımladı. En ciddisi olan CVE-2026-97229, mümkün olan en yüksek önem puanını aldı: 10 üzerinden 10. Bu açık, sunucunuzda hesabı olmayan birinin orada kendi kodunu çalıştırmasına olanak tanıyor. 19.2.8 öncesi 19.2, 19.3.5 öncesi 19.3 veya 19.4.2 öncesi 19.4 sürümlerini çalıştıran her sunucu etkileniyor. GitLab'ın belirttiği tek çözüm 19.4.2, 19.3.5 veya 19.2.8 sürümüne yükseltmek. GitLab.com'daki bulut hizmetini kullanıyorsanız hiçbir şey yapmanıza gerek yok.

GitLab nedir ve bir işletme sahibi neden önemsemeli?

GitLab, teknik ekibinizin sistemlerinizin ve uygulamalarınızın kaynak kodunu sakladığı, yeni sürümlerin derlenip sunucularınıza gönderildiği yerdir. Birçok şirket, kodu ve verileri kurum içinde tutmak için bulut hizmeti yerine onu şirket içi bir sunucuda çalıştırır. Bu sunucu genellikle sahibinin tahmin ettiğinden fazlasını barındırır: kaynak kodun tamamı, veritabanı parolaları, sizi ödeme altyapılarına ve kamu hizmetlerine bağlayan anahtarlar ve müşterilerinizin kullandığı sunuculara dağıtım yapma yetkisi. Onu kontrol eden kişi bunların hepsini okuyabilir ve kodunuzu müşterilerinize ulaşmadan önce değiştirebilir.

GitLab tam olarak ne duyurdu?

GitLab'ın resmi yama sürümü duyurusuna göre açık, derleme ve dağıtım hattı (CI/CD) ayarlarındaki düzenli ifadeleri işleyen bölümde bulunuyor. Düzenli ifade, bir arama kalıbını tanımlayan kısa bir metin parçasıdır. Duyuruda, bu ifadelerin yeterince doğrulanmaması nedeniyle açığın, kimliği doğrulanmamış bir kullanıcının özel olarak hazırlanmış bir düzenli ifade aracılığıyla GitLab sunucusunda rastgele kod çalıştırmasına olanak tanıyabileceği belirtiliyor. Açığı bir araştırmacı, GitLab'ın HackerOne üzerindeki hata ödül programı aracılığıyla bildirdi.

Duyuru, açığın istismar edildiğini söylemiyor. Ancak 10 puan, açığın internet üzerinden, parola olmadan ve hiçbir çalışanın yardımı olmadan istismar edilebileceği anlamına geliyor. Saldırganlar genellikle bir düzeltme kamuya açıklandıktan sonraki birkaç gün içinde bu tür açıkları aramaya başlar, çünkü düzeltmenin kendisi zayıflığın nerede olduğunu gösterir.

Yamada başka neler var?

Aynı yama, beşi yüksek önem derecesinde olmak üzere 23 başka güvenlik açığını daha gideriyor:

  • Sözdizimi vurgulamada kötü amaçlı betik enjeksiyonu (XSS), puanı 8.7.
  • Hat (pipeline) oluştururken bir yetkilendirme açığı, puanı 8.5.
  • Dosya erişimini etkileyen aşırı serbest bir düzenli ifade, puanı 8.2.
  • Ücretli sürümdeki hat yürütme politikalarında bir yetkilendirme açığı, puanı 7.7.
  • Ücretli sürümdeki GitLab Duo yapay zekâ ajanında bir istem enjeksiyonu (prompt injection) açığı, puanı 7.3.

Yani kritik açıktan etkilenmeyen 19.2'den eski sürümler de mutlaka güvenli değil. GitLab'ın resmi bakım politikası, güvenlik düzeltmelerinin yalnızca güncel sürüme ve önceki iki aylık sürüme geriye dönük olarak aktarıldığını söylüyor. Daha eski bir sürümdeki sunucu artık hiç güvenlik düzeltmesi almıyor ve her halükârda yükseltilmesi gerekiyor.

Kimin harekete geçmesi gerekiyor?

  • GitLab.com bulut kullanıcıları: yapılacak bir şey yok; GitLab, hizmetin zaten yamalı sürümü çalıştırdığını söylüyor.
  • GitLab Dedicated müşterileri: duyuruya göre onların da yapacağı bir şey yok.
  • GitLab'ı kendi sunucusunda çalıştıran herkes: hemen yükseltin. Bu, GitLab'ın kendi kendine yönetilen her kurulum için açık önerisi.
  • GitLab'ının nerede çalıştığından emin olmayan herkes: bugün ekibinize ya da sistemlerinizi kuran tedarikçiye sorun. Şirket içi sunucuların çoğu eski bir tedarikçi tarafından kurulup sonra unutulmuştur.

Bu hafta için pratik adımlar

  1. Sürümü bulun: teknik sorumlunuzdan GitLab'daki Yardım sayfasını açmasını, orada gösterilen sürüm numarasını okumasını ve yukarıdaki numaralarla karşılaştırmasını isteyin.
  2. Yükseltmeyi ay sonuna değil bugüne planlayın: GitLab'ın duyurusuna göre tek düğümlü bir sunucu, yama sırasında veritabanı geçişleri bitene kadar kapalı kalır; çok düğümlü kurulumlar ise uygun kesintisiz güncelleme prosedürü izlenirse kesinti olmadan yamalanabilir. Mesai saatleri dışında bir saatlik kesinti, ele geçirilmiş bir sunucudan çok daha ucuzdur.
  3. 19.3 kullanıyorsanız: 19.3.4'e değil, doğrudan 19.3.5'e geçin. Duyuru, 19.3.4'te Ona entegrasyonu etkinken birleştirme isteği (merge request) sayfalarını etkileyen ve 19.3.5'te düzeltilen bir hata olduğunu belirtiyor.
  4. İnternete açıklığı azaltın: şirket dışından kimsenin GitLab sunucunuza erişmesi gerekmiyorsa, sunucunun yalnızca şirket ağından veya bir VPN üzerinden bağlantı kabul etmesini sağlayın. Bu, yamanın yerini tutmaz ama bir dahaki sefere kapıyı daraltır.
  5. Yamadan sonra kontrol edin: yakın zamanda oluşturulan kullanıcıları, anahtarları ve erişim belirteçlerini (token) gözden geçirin. Kimsenin tanımadığı bir şey görünürse sunucuda saklanan parolaları ve anahtarları değiştirin.

Her kurulum yöntemi için yükseltme adımları GitLab'ın resmi yükseltme kılavuzunda yer alıyor.

Origami'nin görüşü

Depolarımız orada bulunduğu için GitLab'ı her gün kullanıyoruz; bu yüzden güvenlik duyurularını faturalarımız kadar yakından takip ediyoruz. Ders GitLab'dan daha geniş: verilerinizi kurum içinde tutmak için kendiniz çalıştırdığınız her sistem, bir düzeltme yayımlandığı gün onu yamalama yükümlülüğünü de beraberinde getirir. En sık gördüğümüz sorun bu kararın kendisi değil, güncellemelerden kimin sorumlu olduğunun belirsiz olması. Üç yıl önce bir tedarikçinin kurduğu ve kimin bakımını yaptığını kimsenin bilmediği bir sunucu, bir saldırganın ilk aradığı şeydir. Aynısını Magento mağaza açığı için de söylemiştik: geç gelirse yalnızca yama yapmak yeterli değildir. Sunucularınızı gözden geçirecek ya da güncellemelerini üstlenecek birine ihtiyacınız varsa bizimle iletişime geçin.

Kaynaklar