GitHub çökünce kendi Git sunucunu kurmak: GitLab ve Gitea'daki iki kritik açığın dersi

Neden herkes kendi Git sunucusunu konuşuyor?

GitHub son aylarda sık sık kesinti yaşadı. Ağustos’taki büyük kesintinin nedenini GitHub kesintisi yazımızda anlattık. Low Level’a göre altta yatan baskılardan biri, yapay zekâ ajanlarıyla katlanarak artan commit sayısı. Bu yüzden bazı ekipler self-hosting’e, yani Git platformunu kendi sunucularında çalıştırmaya bakıyor. En bilinen seçenekler GitLab (Community ve Enterprise sürümleri) ve daha hafif olan Gitea.

Mantıklı bir seçim olabilir. Ama sunucu artık senin sorumluluğunda. GitLab da Gitea da sonuçta kod, kodda da açık çıkar. Son iki ay bunun iki iyi örneğini verdi.

GitLab: Girişsiz dosya okuma (CVE-2026-85706)

GitLab’da istekleri önce Workhorse adlı bir ters vekil (reverse proxy) karşılıyor. Büyük dosya yüklemelerini o tamponluyor, sonra isteği Rails uygulamasına aktarıyor. Hangi yolu kendisinin işleyeceğine bir regex listesiyle karar veriyor.

Açık, iki bileşenin aynı adresi farklı okumasından doğdu. Wiz’in açıklamasına göre yoldaki bir harf yüzde kodlamasıyla yazıldığında (örneğin c yerine %63) Workhorse’un regex’i eşleşmiyor ve istek Workhorse’un dosya işlemesinden geçmeden ilerliyor. Rails tarafı ise adresi çözüp normal commit API’si olarak işliyor. Normalde Workhorse’un geçici bir dosyaya işaret edecek şekilde doldurduğu file.path parametresi, böylece saldırganın yazdığı yol olarak kalıyor. Rails bu dosyayı kimlik doğrulamadan önce açıyor.

Bir de veriyi dışarı çıkarma meselesi var. Bu uç nokta dosya içeriğini geri döndürmek için tasarlanmamış. Ama dosyada geçersiz bir % dizisi varsa, Rack hata mesajı içeriği saldırgana geri gösteriyor. Sonuç: GitLab sürecinin okuyabildiği her dosya, gitlab-secrets.json ve SSH anahtarları dahil. CVSS puanı 10. Yamalar 10 Eylül’de çıktı (19.1.8, 19.2.6, 19.3.2). OffSec’e göre bir gün içinde saldırı denemeleri görüldü.

Gitea: Yama uygulayan uç noktadan Git hook’una (CVE-2026-60004)

Gitea’da diffpatch adlı bir API, bir değişiklik yamasını (patch) geçici bir kopyaya uygulayıp commit’e çeviriyor. Gitea’nın danışma notuna göre aynı yamayı iki kez göndermek bir çakışma yaratıyor. Git’in üç yönlü birleştirme yedeği devreye girip dosyayı deponun iç dizinine yazıyor. Dosyanın adı hooks/post-index-change olursa, artık bir Git hook’u. Git’in belirli anlarda kendiliğinden çalıştırdığı bir betik.

Bunun için depoya yazma yetkisi yeterli. Gitea’da açık kayıt varsayılan olarak etkin olduğu için, dışarıdan gelen biri hesap açıp kendi deposunu oluşturarak saldırabiliyor. Komutlar Gitea’nın çalıştığı kullanıcıyla çalışıyor. Bu root değil, ama bütün depolar ve app.ini içindeki sırlar o kullanıcıya ait. Yani başkalarının gizli depoları da okunabiliyor. Düzeltme 28 Temmuz’da çıkan 1.27.1 sürümünde. Videoya göre internete doğrudan açık binlerce Gitea sunucusu var; güncellenmeyenler hâlâ risk altında.

Ders: Borcu nereye koyacaksın?

Low Level’ın iki videodaki ortak cevabı basit: Kendi sunucunda barındırmak iyi bir fikir olabilir, ama internete açma. Ekibin erişeceği bir Git sunucusunu VPN ya da Tailscale gibi bir özel ağın arkasına koyarsan, bir açık çıktığında yamayı uygulayana kadar zaman kazanırsın. Girişi olan bir sayfa, servisin internete açılmaya hazır olduğu anlamına gelmiyor. Bu iki açığın biri girişten önce, diğeri herkesin açabildiği bir hesapla çalışıyordu.

Bulut servisini seçersen kesintiyi, kendi sunucunu seçersen güncelleme ve güvenlik işini üstlenirsin. İkisi de bir tür borç. Önemli olan hangisini taşıyabileceğini bilerek seçmek.

Düşün

• Kendi sunucunda çalıştırdığın bir servisin yeni sürümünden nasıl haberdar oluyorsun?
• Ekibinin kullandığı araçlardan hangileri gerçekten herkese açık internette durmak zorunda?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.