Sızan bir GitLab issue e-posta adresi herkesin sizin adınıza kod gönderip CI işleri çalıştırmasına olanak tanıyor.
Swati Khandelwal, 23 Eyl 2026, DevOps Security / Supply Chain
GitLab’ın e-posta ile issue açmak için verdiği özel e-posta adresi bir kimlik bilgisi niteliğinde. Bu adrese ulaşan herkes, sizin adınıza herhangi bir dala, hatta main’e bile gönderme yetkiniz olan dala yama gönderebilir ve sizin adınıza CI/CD işleri başlatabilir.
GitLab her kullanıcıya "Bu projeye e-posta ile iş öğesi gönder" etiketli bir düğmenin arkasında bu adresi gösteriyor. Adrese gönderilen posta, sizin adınıza o projede bir issue açıyor.
Adresteki orta kısımda yer alan dize, hesabınıza bağlı bir token ve GitLab’ın dokümantasyonu bunun süresi dolmadığını belirtiyor.
Adres tek bir projeye aitmiş gibi görünüyor. Öyle değil. Davranışı bildiren Aikido Security, GitLab’ın bir kullanıcı için farklı projeler oluşturduğu adreslerin hepsinin aynı token’ı paylaştığını ve bu token’ın hesabın açabildiği her projede, herkese açık veya özel fark etmeksizin geçerli olduğunu buldu.
GitLab e-postayı kimin gönderdiğini kontrol etmiyor. Herhangi bir posta kutusu adrese yazabilir ve GitLab mesajı sanki sizden gelmiş gibi işliyor. Adresi elinde tutan kişi, posta kutunuza hiç dokunmadan sizin gibi hareket edebilir ve izinlerinizle işlem yapabilir.
Adres sadece hata bildirmekten ibaret değil. Aikido, bir kişinin bunu GitLab’ın kendi e-posta ile birleştirme isteği özelliğini kullanarak kod göndermenin bir yoluna dönüştürebileceğini gösterdi:
Adres son ekini -issue’dan -merge-request olarak değiştirin. GitLab böylece bir issue yerine bir birleştirme isteği açar.
Bir yama yazın ve e-posta konu satırına hedef dalın adını yazın.
Yamayı ekleyin ve gönderin. GitLab yamayı ilgili dala uygular ve dal zaten yoksa oluşturur.
Değişiklik, sizin adınıza yazılmış bir commit olarak o dala yerleşir. Gönderme yetkiniz olan bir dalsa bu main’i de kapsar.
Yama projenin .gitlab-ci.yml dosyasını düzenliyorsa ve rolünüz buna izin veriyorsa GitLab saldırganın işini sizin adınıza çalıştırır.
Birleştirme isteği saldırganın kontrol ettiği bir proje kopyasına yönlendirilemez, bu yüzden kod yamayla taşınır, birleştirme isteğiyle değil.
Bu durumun daha kötü olmasını iki şey engelliyor. Token yalnızca kendi izinlerinizi taşır, dolayısıyla saldırganın ne kadar ilerleyebileceği rolünüze bağlıdır. Bir Guest hesabı için sızan bir adres neredeyse işe yaramazken, bir Maintainer için sızan adres korumalı dallara ve CI/CD sırlarına erişebilir.
Bir projeye ulaşmak sadece adresle olmuyor. GitLab hedefi projenin yolundan ve sayısal kimliğinden çıkarıyor, yani saldırgan belirli bir proje istiyorsa token’ın yanı sıra o projenin yolu ve kimliğine de ihtiyaç duyuyor. Herkese açık projeler ikisini de yayınlar. Özel bir proje adını belirten ayrı bir sızıntı gerektirir, ancak GitLab’ın proje kimlikleri tahmin edilmesi kolaydır.
Gelen e-posta IP kısıtlamalarından muaf olduğu için saldırı IP izin listesinden dışarıdan da başlatılabilir. GitLab’ın dokümantasyonu gelen e-postanın IP kısıtlamalarına tabi olmadığını belirtiyor.
Aikido özel bir projeyi kendi adresi olmayan tek bir IP’ye kilitledi. GitLab tarayıcısını engelledi ve git klonlamayı reddetti, ancak birleştirme isteği e-postasını kabul etti ve commit main’e ulaştı.
Aynı yol iki faktörlü kimlik doğrulamayı da atlıyor. GitLab’ın dokümantasyonu gelen e-posta özelliklerinin 2FA olmadan çalıştığını, hatta bunu gerektiren örneklerde bile not ediyor.
Her GitLab.com hesabının böyle bir token’ı var ve gelen e-posta açık olan her kendi kendine yönetilen GitLab örneğinin de var; bu GitLab.com’da varsayılan.
GitLab Dedicated etkilenmiyor gibi görünüyor, çünkü GitLab özelliği kendi kendine yönetilen ve GitLab.com ile sınırlıyor, ancak Aikido Dedicated’ı doğrudan test edemediğini söyledi.
Ne yapmalı
Diğer kişilerin özelliğe sahip olmasını engelleyemezsiniz, ancak sızan bir adresi kesebilirsiniz.
Gelen e-posta token’ınızı profilinizdeki kişisel erişim token’ları sayfasından sıfırlayın. Sıfırlama tüm proje adreslerini bir anda değiştirir, bu yüzden aktif olarak kullandığınız bir adres yeni olanı vermenizle çalışmayı durdurana kadar işlevsiz kalır.
Kendi README’lerinizde, katkı kılavuzlarınızda ve destek sayfalarınızda yayınlanmış bir adres olup olmadığına bakın. Aikido bunun böyle yaklaşık bir düzine canlı adres bulduğunu söyledi, bunların çoğu kasıtlı olarak hata raporu göndermek için yayınlanmış, birkaçı yaygın açık kaynak projelerinde.
Kendi kendine yönetilen bir örnekte yönetici tüm örnek için gelen e-postayı kapatabilir. Bireysel bir kullanıcının e-posta tabanlı issue veya birleştirme isteği oluşturmayı kapatmasına izin veren bir ayar yok.
GitLab, Aikido’nun raporundan sonra token çevresindeki metni değiştirdi. Açıklama artık adresin issue ve birleştirme istekleri oluşturabileceğini söylüyor, daha önce yalnızca iş öğeleri listeleniyordu ve GitLab token’ın başka hiçbir veriye erişmek için kullanılamayacağını belirten bir satırı kaldırdı.
Davranış değişmedi. Token hâlâ süresi dolmuyor, GitLab hâlâ e-postayı kimin gönderdiğini kontrol etmiyor ve bireysel bir kullanıcının özelliği kapatması için hâlâ bir anahtar yok.
GitLab, bu e-postaları yalnızca hesap sahibinde doğrulanmış bir adresten kabul etmeye bakmak için bir issue açtı, ancak bu değerlendirme aşamasında, uygulanmış değil.
Aikido, davranışı ilk olarak Mayıs 2026’da HackerOne üzerinden bildirdiğini, burada amaçlanan davranış olarak kapatıldığını ve ardından Haziran’da GitLab’a gizli bir issue açtığını söyledi. Aikido’nun aktardığına göre GitLab’ın pozisyonu bunun herhangi bir token gibi bir token olduğu ve sızan her kimlik bilgisinin kötü sonuçlara yol açtığı yönünde.
The Hacker News GitLab ve Aikido’ya yorum için ulaştı.
