Alamat Email Proyek GitLab yang Terbuka Dapat Dimanfaatkan untuk Mendorong Kode

Peneliti keamanan memperingatkan adanya risiko pada fitur Email work item to this project milik GitLab yang dapat disalahgunakan apabila alamat email khusus proyek sengaja dipublikasikan di dokumentasi.

Alamat tersebut dirancang untuk memungkinkan developer membuat issue atau task GitLab melalui email. Namun, alamat email yang dihasilkan secara otomatis juga mengandung token jangka panjang yang berfungsi sebagai kredensial untuk mengakses proyek.

Jika alamat email tersebut bocor dan ditemukan oleh pihak lain, penyerang berpotensi membuat issue atau merge request atas nama pemilik token. Dalam kondisi tertentu, dampaknya dapat berkembang menjadi perubahan kode, eksekusi pipeline CI/CD, akses ke repository privat, hingga pencurian secret yang tersimpan di variabel CI/CD.

Temuan ini diungkap oleh perusahaan keamanan aplikasi Aikido setelah menemukan sejumlah alamat email GitLab privat yang sengaja dicantumkan dalam README, panduan kontribusi, serta halaman dukungan untuk menerima laporan bug.

Alamat Email GitLab Mengandung Token yang Berfungsi sebagai Kredensial

GitLab menyediakan fitur untuk membuat work item melalui email. Ketika alamat email khusus tersebut menerima pesan, GitLab akan memprosesnya dan mengubah isi email menjadi issue atau task pada proyek yang terkait.

Masalahnya, alamat email tersebut bukan sekadar alamat penerima biasa.

Di dalam setiap alamat terdapat string glimt- yang berfungsi sebagai token untuk mengakses proyek. Token tersebut memiliki masa berlaku panjang dan tetap terkait dengan proyek yang bersangkutan.

Artinya, siapa pun yang memperoleh alamat email tersebut dapat menggunakannya untuk mengirim permintaan ke GitLab seolah-olah berasal dari pemilik kredensial tersebut.

Risiko semakin besar karena alamat tersebut terkadang sengaja dipublikasikan dalam dokumentasi proyek agar pengguna dapat mengirim laporan bug.

Alamat Issue Dapat Diubah Menjadi Merge Request

Dalam pengujian Aikido, peneliti menemukan bahwa alamat email yang awalnya digunakan untuk membuat issue dapat dimodifikasi untuk membuat merge request.

Caranya adalah dengan mengubah bagian suffix pada alamat email dari -issue menjadi -merge-request.

GitLab kemudian akan memproses email tersebut sebagai permintaan untuk membuat merge request pada proyek yang bersangkutan.

Dengan demikian, kebocoran alamat email privat tidak hanya memungkinkan seseorang membuat issue palsu. Dalam kondisi tertentu, alamat tersebut dapat digunakan untuk melakukan tindakan yang lebih dekat dengan proses perubahan kode.

Aikido juga menemukan bahwa pengirim email tidak harus menggunakan alamat email milik pemilik token.

Penyerang cukup mengirim email dari mailbox apa pun di internet. GitLab tetap memproses pesan tersebut menggunakan hak akses yang terkait dengan token pada alamat email proyek.

Pemeriksaan Alamat Pengirim Tidak Menjadi Lapisan Perlindungan

Salah satu mitigasi yang secara teori dapat mengurangi risiko adalah memastikan bahwa alamat pengirim email sama dengan alamat email pemilik token.

Namun, menurut Aikido, GitLab saat ini tidak melakukan pemeriksaan tersebut.

Akibatnya, mengetahui alamat email khusus proyek sudah cukup untuk memungkinkan pihak lain mengirim email ke endpoint tersebut dan memanfaatkan kredensial yang tertanam di dalam alamat.

GitLab diketahui sedang mempertimbangkan perubahan terhadap mekanisme tersebut.

Aikido juga menemukan bahwa mekanisme ini dapat melewati pembatasan berdasarkan IP address. Dengan kata lain, pembatasan akses berdasarkan alamat IP tidak secara otomatis mencegah penyalahgunaan endpoint email tersebut.

Dampaknya Bergantung pada Hak Akses Akun

Kebocoran alamat email tidak otomatis memberikan akses administrator penuh ke GitLab. Dampak akhirnya tetap bergantung pada hak akses pengguna yang terkait dengan token tersebut.

Namun, apabila akun memiliki izin yang cukup tinggi, penyerang dapat memperoleh kemampuan untuk melakukan berbagai aktivitas berbahaya, seperti:

• Membuat atau memodifikasi perubahan kode.
• Membuat merge request.
• Menjalankan pipeline CI/CD.
• Mengakses repository privat.
• Mengambil secret dari variabel CI/CD.
• Mengakses issue atau informasi internal proyek.
• Memengaruhi proses build dan deployment.

Dalam lingkungan pengembangan software, akses terhadap pipeline CI/CD memiliki nilai yang sangat tinggi. Jika pipeline memiliki kredensial untuk cloud, registry container, deployment server, atau layanan produksi, kompromi pada proyek dapat berkembang menjadi serangan terhadap infrastruktur di luar GitLab.

Penyerang Tetap Membutuhkan Informasi Proyek

Menurut Aikido, terdapat beberapa batasan yang masih berlaku.

Penyerang harus mengetahui project path dan project ID untuk dapat memanfaatkan mekanisme tersebut.

Pada proyek publik, informasi tersebut biasanya mudah ditemukan karena memang tersedia untuk umum.

Sementara pada proyek privat, project ID dapat dicoba melalui brute-force, tetapi project path tetap harus diketahui atau diperoleh melalui kebocoran informasi lainnya.

Selain itu, hak akses akun tetap menjadi pembatas yang tidak dapat dilewati hanya dengan mengetahui alamat email proyek.

Karena itu, tingkat dampak setiap kasus dapat berbeda tergantung konfigurasi proyek dan permission akun yang terhubung dengan alamat tersebut.

GitLab Sudah Memperingatkan Bahaya Membocorkan Alamat Ini

GitLab sebenarnya telah memberikan peringatan dalam dokumentasinya mengenai sifat sensitif alamat email tersebut.

Alamat tersebut dijelaskan sebagai alamat privat yang dibuat khusus untuk pengguna. GitLab memperingatkan bahwa siapa pun yang mengetahuinya dapat membuat issue atau merge request seolah-olah berasal dari pengguna yang memiliki alamat tersebut.

GitLab juga menyarankan pengguna untuk segera melakukan reset token apabila mencurigai alamat email privat tersebut telah bocor.

Hal ini menunjukkan bahwa alamat email tersebut seharusnya diperlakukan seperti kredensial, bukan sebagai alamat email biasa yang aman untuk dicantumkan dalam dokumentasi publik.

Aikido Menemukan Belasan Alamat di Proyek Publik

Dalam satu sore, peneliti Aikido menemukan sekitar selusin alamat email GitLab aktif yang tersedia di berbagai README, panduan kontribusi, dan halaman dukungan publik.

Alamat tersebut ditemukan karena maintainer proyek sengaja mencantumkannya agar pengguna dapat mengirim laporan bug atau masalah lainnya melalui email.

Beberapa alamat bahkan ditemukan pada proyek open-source yang populer.

Kondisi tersebut menimbulkan risiko supply-chain attack, karena satu proyek open-source dapat digunakan oleh banyak organisasi dan aplikasi. Jika penyerang berhasil memanfaatkan akses untuk memasukkan kode berbahaya ke dalam proyek yang banyak digunakan, dampaknya dapat meluas ke pengguna dan downstream projects.

GitLab Menganggap Perilaku Ini sebagai Intended Behavior

Aikido mengatakan telah melaporkan masalah tersebut kepada GitLab melalui HackerOne pada Mei 2026.

GitLab kemudian menutup laporan tersebut dengan status intended behavior.

Aikido kembali memberikan pemberitahuan pada Juni. Setelah itu, GitLab melakukan sejumlah perubahan pada antarmuka dan dokumentasinya, termasuk menambahkan informasi bahwa alamat tersebut dapat digunakan untuk membuat merge request, menghapus pernyataan yang dianggap keliru mengenai akses token, serta mendokumentasikan bahwa incoming email dapat melewati pembatasan IP.

Dengan demikian, mekanisme tersebut bukan diperlakukan sebagai kerentanan yang perlu dihilangkan sepenuhnya oleh GitLab, tetapi sebagai fitur dengan konsekuensi keamanan yang perlu dipahami oleh pengguna.

Maintainer Disarankan Tidak Mempublikasikan Alamat Email

Bagi maintainer GitLab, langkah paling penting adalah tidak mencantumkan alamat email privat proyek tersebut di README, dokumentasi kontribusi, halaman dukungan, atau lokasi publik lainnya.

Jika alamat tersebut sebelumnya pernah dipublikasikan, token sebaiknya segera di-reset karena alamat lama harus dianggap sudah tidak lagi rahasia.

Pengelola proyek juga perlu memeriksa permission akun yang terhubung dengan token. Semakin tinggi hak akses akun, semakin besar dampak yang dapat ditimbulkan apabila alamat email tersebut ditemukan dan disalahgunakan.

Untuk proyek open-source yang digunakan oleh banyak pihak, pemeriksaan ini menjadi semakin penting karena kebocoran kredensial pada satu repository dapat berpotensi memengaruhi rantai pasokan software.

Kasus ini juga menjadi pengingat bahwa kredensial tidak selalu terlihat seperti password atau API key. Sebuah alamat email otomatis yang mengandung token autentikasi harus diperlakukan sebagai informasi rahasia apabila alamat tersebut dapat digunakan untuk melakukan tindakan atas nama akun atau proyek.

Sumber: Aikido