Eylül 11 sabahı saatler içinde başlayan saldırılar
11 Eylül 2026 sabahı saat 06:00 UTC'de, watchTowr Labs'in honeypot ağı GitLab sunucularını hedef alan ilk davranışsal saldırı denemelerini tespit etti. Saldırganlar, yalnızca birkaç saat önce açıklanan CVE-2026-85706 açığını kullanarak açık internete erişime sahip GitLab kurulumlarını taramaya başlamıştı. Açığın CVSS puanı 10.0 ve kimlik doğrulaması gerektirmiyor.
Saldırı basit: tek bir HTTP POST isteği, /api/v4/projects/{id}/repository/commits/ endpoint'ine file.Path parametreleri içerecek şekilde gönderiliyor. Bu istek, sunucudaki log dosyalarını, GitLab yapılandırma dosyalarını ve kimlik bilgilerini okumaya izin veriyor. Saldırganın ihtiyacı olan tek şey: hedef GitLab sunucusunda en az bir public proje olması.
GitLab'ın 10 Eylül'de yayınladığı yamalar bu açığı kapatıyor. Ancak yama ile saldırı arasındaki pencere 24 saatten kısa sürdü — self-hosted GitLab kullanan kuruluşlar için dar bir müdahale penceresi.
CVSS 10.0 açığının anatomisi: repository commits API'de path traversal
CVE-2026-85706'nın tehlikeli olmasının nedeni iki kontrolün aynı anda eksik olması: improper path confinement (yol kısıtlamasının eksikliği) ve missing authentication enforcement (kimlik doğrulama zorunluluğunun eksikliği).
GitLab'ın repository commits API endpoint'i, kullanıcıların commit verilerini sorgulamasına izin veriyor. Ancak bu endpoint'te yol doğrulaması yetersiz. Saldırgan file.Path parametresine ../../../ gibi path traversal karakterleri ekleyerek, repository dışındaki sunucu dosyalarına erişebiliyor.
Bu işlem kimlik doğrulaması gerektirmiyor. Saldırgan GitLab kullanıcısı olmak zorunda değil. Tek gereklilik, hedef GitLab sunucusunda bir public proje olması — ki çoğu self-hosted GitLab kurulumunda bu koşul sağlanıyor.
Saldırganın okuyabileceği dosyalar arasında:
- GitLab log dosyaları (kullanıcı aktivitesi, API çağrıları, hata mesajları) - gitlab.rb ve benzer yapılandırma dosyaları - Veritabanı bağlantı bilgileri - Secret token'lar ve şifreleme anahtarları - Backup dosyaları ve sistem yapılandırması
watchTowr'un honeypot ağında tespit edilen ilk denemeler, açığın script edilebilir ve otomasyona uygun olduğunu gösteriyor.
Hangi GitLab kurulumları tehdit altında
Tüm GitLab kullanıcıları risk altında değil. Açık yalnızca self-managed ve self-hosted GitLab kurulumlarını etkiliyor.
Güvende olanlar:
- GitLab.com üzerinde barındırılan projeler (GitLab'ın SaaS hizmeti) - GitLab Dedicated müşterileri (single-tenant bulut hizmeti)
Risk altında olanlar:
- Şirket sunucularında veya VPS'lerde self-hosted GitLab CE/EE kurulumları - Açık internete erişime açık GitLab sunucuları - En az bir public repository barındıran GitLab örnekleri
GitLab.com kullanıcıları güvenli çünkü GitLab bu ortamları kendisi yönetiyor ve yamaları merkezi olarak uyguluyor.
Ancak self-hosted GitLab kullanıcıları — özellikle açık internetten erişilebilen kurulumlar — en yüksek riske maruz. Açık internetten erişilebilen GitLab sunucuları untargeted saldırılara karşı en savunmasız grup.
Etkilenen sürümler ve yamaların uygulanması
CVE-2026-85706 şu GitLab sürümlerini etkiliyor:
- 18.7 serisi: 19.1.8 öncesi tüm sürümler - 19.2 serisi: 19.2.6 öncesi tüm sürümler - 19.3 serisi: 19.3.2 öncesi tüm sürümler
GitLab 10 Eylül 2026'da üç yamalı sürüm yayınladı:
- 19.1.8 - 19.2.6 - 19.3.2
Self-managed GitLab kullanan kuruluşlar bu sürümlerden birine hemen güncelleme yapmalı.
Güncelleme senaryonuz:
- 18.7.x kullanıyorsanız: 19.1.8'e yükseltin. - 19.2.x kullanıyorsanız: 19.2.6'ya yükseltin. - 19.3.x kullanıyorsanız: 19.3.2'ye yükseltin.
GitLab'ın yama yayın hızı iyi, ancak saldırı deneme hızı daha iyi: watchTowr Labs, açıklamadan saatler içinde davranışsal problar gözlemledi.
Federal ve organizasyonel yanıt: CISA deadline ve KEV listesi
Amerika Birleşik Devletleri Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), CVE-2026-85706'yı Known Exploited Vulnerabilities (bilinen sömürülen açıklar) kataloğuna ekledi. Bu, açığın yalnızca teorik değil, pratikte sömürüldüğünü onaylıyor.
CISA'nın direktifi açık: federal sivil yönetim kurumları (FCEB) 14 Eylül 2026 tarihine kadar yamalamak zorunda. Bu, yama yayın tarihinden itibaren yalnızca 4 günlük bir süre.
FCEB dışındaki kuruluşlar bu deadline'a yasal olarak bağlı değil. Ancak CISA'nın KEV listesi, diğer kuruluşlar için de bir risk sinyali olarak kabul ediliyor.
CVE-2026-85706, son haftalarda GitLab'ın yayınladığı ikinci kritik açık. Önceki açık — CVE-2026-19478, bir GraphQL code injection açığı — yayından neredeyse hemen sonra sömürülmeye başlamıştı. Bu kalıp, GitLab kullanıcılarının yama yayın hızına daha fazla dikkat etmesi gerektiğini gösteriyor.
Path traversal açıkları nedir ve neden tehlikeli
Path traversal (yol dolaşma), bir saldırganın web uygulamasının izin verdiği dizin dışındaki dosyalara erişmesini sağlayan bir güvenlik açığı türü. Açık, uygulama dosya yollarını yeterince doğrulamadığında ortaya çıkıyor.
Normal bir dosya okuma isteği şu şekilde olabilir:
`` /api/v4/projects/123/repository/commits/?file=README.md ``
Bu istek yalnızca repository içindeki README.md dosyasını okumalı. Ancak path confinement (yol sınırlaması) eksikse, saldırgan ../ karakterleri ekleyerek üst dizinlere çıkabilir:
`` /api/v4/projects/123/repository/commits/?file=../../../../etc/passwd ``
CVE-2026-85706'da sorun şu: GitLab'ın repository commits API'si bu tür yol dolaşmalarını engellemiyor. Saldırgan file.Path parametresi ile repository dışındaki dosyalara — sistem yapılandırmasına, log dosyalarına, kimlik bilgilerine — erişebiliyor.
İkinci sorun: kimlik doğrulaması eksikliği. Çoğu path traversal açığı, saldırganın oturum açmasını veya yetkili bir kullanıcı olmasını gerektiriyor. Ancak CVE-2026-85706'da bu kısıtlama yok. Saldırgan anonim olarak, public bir proje varsa hemen saldırıya geçebiliyor.
Bu kombinasyon — path traversal + authentication bypass — CVSS 10.0 puanını haklı çıkarıyor.
Immediate actions for exposed self-hosted instances
Self-hosted GitLab kullanıyorsanız ve sunucunuz açık internetten erişilebilir durumdaysa, şu adımları hemen uygulamalısınız:
1. HTTP POST loglarınızı kontrol edin
Sunucu loglarınızda /api/v4/projects/{id}/repository/commits/ URI'sine yapılan HTTP POST isteklerini arayın. Özellikle file.Path parametresi içeren isteklere dikkat edin. GitLab bu logları incelemenizi öneriyor çünkü sömürü denemelerini tespit etmenin en doğrudan yolu bu.
Tipik bir saldırı isteği şu şekilde görünebilir:
`` POST /api/v4/projects/123/repository/commits/ Content-Type: application/json {"file.Path": "../../../config/gitlab.yml"} ``
Eğer loglarınızda bu tür istekler varsa, sistemin zaten sömürülmüş olabileceğini varsaymalısınız.
2. Hemen yamalı sürüme yükseltin
GitLab'ı 19.1.8, 19.2.6 veya 19.3.2'ye güncelleyin. Yama süreci GitLab'ın resmi güncelleme kılavuzunu izlemelidir. Yedekleme almadan güncelleme yapmayın.
3. Network erişim sınırlandırması yapın
Eğer GitLab sunucunuzun açık internetten erişilebilir olması gerekli değilse, firewall veya VPN ile erişimi sınırlandırın. Yalnızca belirli IP aralıklarından veya kurumsal ağdan erişime izin verin.
Eğer public projeler barındırıyorsanız ve açık erişim gerekiyorsa, en azından kritik API endpoint'lerine rate limiting ve anomaly detection uygulayın.
4. Credential rotation ve güvenlik incelemesi
Eğer sömürü kanıtı varsa — log dosyalarında şüpheli istekler tespit ettiyseniz — tüm GitLab kimlik bilgilerini, secret token'ları ve API anahtarlarını değiştirin. Backup dosyalarını ve yapılandırma dosyalarını gözden geçirin.
Eğer GitLab sunucunuz diğer sistemlere (CI/CD pipeline'lar, dış veritabanları, cloud provider API'leri) bağlıysa, bu bağlantıların kimlik bilgilerini de değiştirmeniz gerekebilir.
5. İzleme ve tespit araçları kurun
Gelecekteki saldırıları erken tespit etmek için GitLab'a özel güvenlik izleme araçları ekleyin. /api/v4/projects/ endpoint'lerine yapılan anormal POST istekleri için uyarı kuralları oluşturun.
Self-hosted GitLab kullanıyorsanız, HTTP POST loglarınızı kontrol edin, yamalı sürüme hemen yükseltin ve network erişim politikanızı gözden geçirin. Federal kurumlar gibi 14 Eylül deadline'ınız olmayabilir, ancak saldırganlar zaten hareket etti.
