3 Kasım 2026 - 17:39
GitLab'ı Güncelledim, Açık Neden Kapanmadı? Alpine Olayı ve Ruby Kontrolü Görseli
Siber Güvenlik

GitLab'ı Güncelledim, Açık Neden Kapanmadı? Alpine Olayı ve Ruby Kontrolü

0 Yorumlar

GitLab'ı güncelledin, sürüm numarası da doğru görünüyor. Peki güvenlik açığı gerçekten kapandı mı? Alpine Linux'un yaşadığı olay, bu sorunun cevabının kurulum biçimine bağlı olduğunu gösteriyor. Uygulama güncellenirken onu çalıştıran Ruby eski kalabiliyor.

Burada iki ayrı parçaya bakacağız: GitLab sürümü ve GitLab'ın kullandığı Ruby. Ruby, GitLab'ın çalıştığı programlama dili ortamı. Terminalde gördüğün herhangi bir ruby -v çıktısı, GitLab'ın da aynı çalıştırıcıyı kullandığını kanıtlamıyor.

Alpine'da ne oldu?

Alpine'ın olay açıklamasına göre 20–21 Ekim'de GitLab sunucusuna CVE-2026-97229 üzerinden saldırı girişimleri yapıldı. Ardından GitLab 19.3.6'ya yükseltildi; ancak özel imajdaki Ruby, GitLab'ın resmi paketlerine eklediği yamayı içermiyordu. Dolayısıyla uygulamanın sürümü değiştiği halde alttaki sorun devam etti.

Alpine, saldırganın kod çalıştırdığına dair kanıt bulamadığını, fakat bunu tamamen dışlayamadığını açıkladı ve sistemi yeniden kurdu. Paketler ile sürüm dosyalarında değişiklik tespit edilmedi. Duyurunun 30 Ekim güncellemesinde GitLab'ın yeniden açıldığı belirtiliyor. Bu olayı “Alpine paketleri ele geçirildi” diye okumamak gerekiyor.

Hangi sürümlerden söz ediyoruz?

CVE-2026-97229, GitLab'ın otomatik test ve dağıtım işlerini tanımlayan CI/CD yapılandırmasındaki düzenli ifadelerle ilişkili. Düzenli ifade, metinde belirli bir kalıbı aramak için kullanılan kuraldır. Buradaki hata, bu kural işlenirken bellek bozulmasına ve belirli koşullarda uzaktan kod çalıştırılmasına yol açabiliyor.

GitLab CE/EE dalı12 Ekim duyurusunda etkilenen aralıkİlk düzeltilmiş resmi sürüm
19.219.2.8 öncesi19.2.8
19.319.3.5 öncesi19.3.5
19.419.4.2 öncesi19.4.2

Tablo bu CVE'nin ilk düzeltme duyurusunu gösteriyor; bugün kurulacak en güncel sürüm listesi değil. 21 Ekim'deki ayrı güvenlik yayını, CVE-2026-110264 dahil başka düzeltmeler de içeriyor. Eski bir dalı sırf yukarıdaki numaraya eşitledin diye bütün açıkların kapandığını varsayma.

Önce hangi Ruby'nin çalıştığını bulalım

Resmi Linux paketiyle kurulumda ortam bilgisini şu görevle okuyabilirsin. Bu, sürüm incelemesidir; tek başına güvenlik taraması yapmaz:

BASH
sudo gitlab-rake gitlab:env:info
/opt/gitlab/embedded/bin/ruby -v

İkinci yol resmi Linux paketindeki gömülü Ruby içindir. Kendi derlemen veya farklı imajın varsa bu dosya bulunmayabilir. Çok düğümlü kurulumda ortam görevini GitLab Rails çalıştıran düğümde kullan; veritabanı sunucusunda aynı komutu arama. Ayrıntılar GitLab bakım görevlerinde yer alıyor.

Docker kullanıyorsan aşağıdaki gitlab örnek konteyner adını kendininkiyle değiştir. İlk komut imaj referansını ve çalışan imaj kimliğini gösterir; ikincisi resmi paket yapısını kullanan konteynerin içindeki ortamı okur:

BASH
docker inspect --format '{{.Config.Image}} {{.Image}}' gitlab
docker exec gitlab gitlab-rake gitlab:env:info

Özel imajda servis farklı bir Ruby yolu kullanıyorsa denetimi o çalıştırıcıyla yap. Etiketi aynı kalan yeni bir imajı indirmek de mevcut konteyneri kendiliğinden yenilemez. Çalışan imaj kimliği ile dağıtıma aldığın imajı karşılaştır.

Düzeltmeyi kurulum biçimine göre uygula

Resmi GitLab paketi veya resmi imaj kullanıyorsan desteklenen yükseltme yolunu izle. Büyük sürüm aralıklarını tek atlayışta geçmek yerine gerekli ara durakları ve veritabanı geçişlerini kontrol et. Yükseltmeden önce geri yüklenebilir yedek ve bakım planı hazır olmalı.

Kendi Ruby'nle çalışıyorsan yalnız GitLab paketini değiştirmek yetmez. Ruby'nin toplu düzeltme duyurusu, ilgili hataların tamamını içeren 3.3.13, 3.4.12 ve 4.0.9 sürümlerini listeliyor. GitLab'ın desteklediği Ruby dalında düzeltilmiş sürümü seç; rastgele 4.0'a geçme. CVE-2026-97229'un altındaki düzeltme 4.0 dalında 4.0.8'de bulunuyor, 4.0.9 ise duyurudaki dört sorun için ortak düzeltme seviyesidir. Dağıtıcı yamayı eski sürüm numarasına taşıdıysa paket revizyonu ve güvenlik duyurusunu birlikte doğrula.

Yeni çalıştırıcı kurulduktan sonra servislerin gerçekten onunla yeniden başlatıldığını ve işlerin çalıştığını kontrol et. Yama, geçmişte gerçekleşmiş olabilecek bir saldırıyı temizlemez: şüpheli işçi çökmeleri veya beklenmeyen CI hareketleri varsa kayıtları koruyup GitLab'ın tespit önerileriyle olay incelemesini ayrıca yürüt. Son kontrolde yalnız web arayüzündeki GitLab numarası değil, çalışan Ruby ve kullanılan paket ya da imaj da kayıt altında olsun.

Benzer Yazılar

Yorumlar (0)

Henüz yorum yok. İlk yorum yapan sen ol!

Yorum Yap