GitLab’te bir kullanıcıya özel görünen e-posta adresi, ele geçirildiğinde o kullanıcı adına issue açmanın ötesine geçip kod gönderme ve CI işlerini çalıştırma yoluna dönüşebiliyor. Güvenlik araştırmacıları, token yapısındaki bu adresin geçerliliğini yitirmediğini ve aynı hesabın açabildiği tüm projelerde kullanılabildiğini ortaya koydu.
İnceleme, GitLab’in “Email work item to this project” düğmesinin arkasında ürettiği adreslerin tek bir projeye bağlıymış gibi görünmesine rağmen aslında hesap düzeyinde çalıştığını gösterdi. Adresin ortasındaki token, kullanıcının hesabına bağlı ve GitLab dokümantasyonuna göre süresi dolmuyor. Bu da adresi gören biri için, o hesabın yetkileriyle projeye içerik gönderebilmek anlamına geliyor.
Aynı token tüm projelerde geçerli
Bulguları paylaşan Aikido Security, GitLab’in farklı projeler için ürettiği e-posta adreslerinin aynı token’ı kullandığını tespit etti. Token, hesabın açabildiği her projede çalışıyor; ister açık ister özel olsun, yetki kapsamı hesabın erişebildiği alanla sınırlı kalıyor. GitLab de gönderilen e-postanın gerçekten kimden geldiğini kontrol etmiyor. Bu yüzden herhangi bir posta kutusu, o adrese mesaj yolladığında sistem bunu kullanıcıdan gelmiş gibi işliyor.
Bu yapı, adresin sahibi adına işlem yapılmasına izin veriyor. E-postayı gönderen kişi, hedef hesabın posta kutusuna hiç dokunmadan, GitLab üzerinde o kullanıcıymış gibi hareket edebiliyor. Mekanizma yalnızca issue açmakla sınırlı değil; merge request akışı da aynı e-posta tabanlı yoldan tetiklenebiliyor.
Aikido’nun gösterdiği yöntemde saldırgan, adresin sonundaki -issue kısmını -merge-request olarak değiştiriyor. Böylece GitLab, issue yerine doğrudan bir merge request oluşturuyor. Ardından e-postaya bir yama ekleniyor ve hedef dalın adı konu satırına yazılıyor. Mesaj gönderildiğinde GitLab yamayı ilgili dala uyguluyor; dal yoksa dalı da oluşturuyor.
Ortaya çıkan commit, hedef kullanıcı adına yazılmış görünüyor. Eğer o kullanıcı, ilgili dala push yetkisine sahipse işlem ana dal dahil erişebildiği her dalda geçerli oluyor. Yama proje içindeki .gitlab-ci.yml dosyasını değiştirirse ve kullanıcının rolü buna izin veriyorsa, GitLab saldırganın işini yine o kullanıcı adına çalıştırıyor.
Burada merge request’in doğrudan saldırganın kontrolündeki bir kopyaya yönlendirilmesi gerekmiyor. Kod, merge request nesnesinin kendisinden değil, e-postaya eklenen yamadan taşınıyor. Bu yüzden istismar zincirinin kritik noktası, mesajın içine eklenen içerik oluyor.
Erişim, IP kısıtları ve 2FA’yı da aşıyor
Riskin boyutu, kullanıcının rolüne göre değişiyor. Aikido’nun değerlendirmesine göre Guest hesabına ait sızmış bir adres pek işe yaramazken, Maintainer yetkilerine sahip bir hesap için aynı adres korumalı dallara ve CI/CD sırlarına kadar uzanabiliyor. Token yalnızca kullanıcının kendi izinlerini taşıdığı için etki alanını belirleyen unsur, token’ın kime ait olduğu oluyor.
Bir projeye ulaşmak için adres tek başına da yeterli değil. GitLab, hedefi projenin yolu ve sayısal kimliği üzerinden belirliyor. Bu nedenle saldırganın belirli bir projeyi hedefleyebilmesi için token’ın yanında projenin yolu ve ID’si de gerekiyor. Açık projelerde bu bilgiler genellikle görülebilir durumda. Özel projelerde ise hedefi isimlendiren ayrı bir sızıntı şart, ancak proje ID’leri tahmin edilmesi görece kolay değerler arasında yer alıyor.
Gelen e-posta trafiği IP kısıtlamalarından muaf olduğu için saldırı, bir IP allowlist dışından başlayabiliyor. GitLab dokümantasyonu da incoming email işlemlerinin IP kısıtlarına tabi olmadığını söylüyor. Aikido, özel bir projeyi yalnızca kendisine ait olmayan tek bir IP adresine kilitlediğini, GitLab’in tarayıcı erişimini engelleyip git clone talebini reddettiğini, ancak merge request e-postasını kabul ettiğini aktardı. Sonunda commit main dalına işlendi.
Aynı yol, iki aşamalı doğrulamayı da devre dışı bırakıyor. GitLab dokümanında incoming email özelliklerinin 2FA gerektiren ortamlarda bile without 2FA çalıştığı belirtiliyor. Böylece e-posta tabanlı işlem, oturum açma akışına ve normal kullanıcı doğrulamasına uğramadan ilerleyebiliyor.
Bu mekanizma GitLab.com üzerindeki her hesapta bulunuyor. Aynı yapı, incoming email özelliği açık olan tüm self-managed GitLab kurulumlarında da geçerli. GitLab.com tarafında bu özelliğin varsayılan olarak açık olması, kapsamı daha da genişletiyor. GitLab Dedicated için ise doğrudan test yapılamadığı için etkilenip etkilenmediği netleştirilemedi; şirketin özelliği yalnızca self-managed ve GitLab.com ile sınırladığı not edildi.
GitLab’in konuya ilişkin metinlerini de Aikido raporunun ardından güncellediği görüldü. Token açıklamasında artık adresin issue ve merge request oluşturabildiği yazıyor. Daha önce metinde yalnızca work item ifadesi vardı; ayrıca token’ın başka hiçbir veriye erişemeyeceğini belirten satır da kaldırıldı. Buna karşın davranışın kendisi değişmedi: token hâlâ süresiz, GitLab hâlâ göndereni doğrulamıyor ve bireysel kullanıcıların bu özelliği kapatabileceği bir anahtar bulunmuyor.
Şirketin açıkladığına göre bir çözüm seçeneği üzerinde ayrıca duruluyor. GitLab, bu e-postaları yalnızca hesap sahibi tarafından doğrulanmış bir adresten kabul etmeyi değerlendirmek için bir issue açtı. Ancak bu, alınmış bir karar değil; sadece inceleme aşamasında.
Aikido, davranışı ilk olarak Mayıs 2026’da HackerOne üzerinden bildirdiğini, ancak bildirimin “beklenen davranış” olarak kapatıldığını söyledi. Ardından Haziran ayında GitLab’e gizli bir issue açıldı. Aikido’nun aktardığına göre GitLab, bunun diğer token’lar gibi bir token olduğunu ve herhangi bir sızmış kimlik bilgisinin kötü sonuçlara yol açabileceğini savundu.
GitLab tarafında konuya dair resmi yorum beklenirken, Aikido’nun bulguları açık proje adreslerinin, README dosyalarının, katkı rehberlerinin ve destek sayfalarının taranmasıyla da çok sayıda canlı adresin bulunabildiğini ortaya koydu. Şirket bu yöntemle yaklaşık bir düzine çalışan adres saptadığını, bunların çoğunun bilerek yayımlandığını ve bir kısmının da yaygın açık kaynak projelerinde yer aldığını bildirdi.
Olası etkileri azaltmak için yapılabilecek ilk işlem, token’ı sıfırlamak. GitLab, incoming email token’ının profil içindeki personal access tokens sayfasından yenilenebildiğini belirtiyor. Sıfırlama işlemi, o kullanıcıya bağlı tüm proje adreslerini bir anda değiştiriyor. Bu da aktif kullanılan adreslerin, yeni adres dağıtılana kadar çalışmaması anlamına geliyor.
Self-managed bir kurulumda sistem yöneticisi, incoming email özelliğini tüm instance için kapatabiliyor. Ancak kullanıcı bazında, e-posta ile issue ya da merge request oluşturmayı kapatan bir ayar bulunmuyor. Bu nedenle riskin kapatılması kurulum seviyesinde mümkün; tekil kullanıcı seviyesinde ise böyle bir kontrol yer almıyor.