Emel Isu GitLab: Token Push-to-Main Sebenarnya

Alamat Emel Isu GitLab Ternyata Sebuah Token

Dalam profil GitLab anda ada satu butang bernama "Email work item to this project". Tekan, dan GitLab bagi satu alamat emel peribadi — nampak macam alamat biasa, sebab memang ia emel. Hantar apa-apa ke alamat itu, satu issue muncul dalam projek itu dengan nama anda sebagai author. Bunyinya macam ciri yang memudahkan semata-mata.

Penyelidikan Aikido Security yang diterbitkan pada 23 September 2026 menunjukkan alamat itu sebenarnya satu credential yang menyamar sebagai emel — dan kuasanya mengejutkan. Token di tengah-tengah alamat itu terikat pada akaun anda, tak pernah luput, menjangkau setiap projek yang anda boleh capai, dan sesiapa yang memegangnya boleh tolak kod serta jalankan CI/CD job atas nama anda.

Alamat emel yang sebenarnya bukan skop projek

Butang yang sama muncul dalam setiap projek, dan setiap projek nampaknya memberi alamat yang berbeza. Tapi bahagian yang paling penting tetap sama:

incoming+<project-id>-glimt-<token>[email protected]

String glimt- itu ialah token jangka panjang yang terikat pada akaun anda — bukan pada projek atau peti emel tertentu. Dokumen rasmi GitLab sendiri menyatakan token ini tidak luput. Buka butang itu dalam lima projek berbeza, sama ada public atau private, token yang tertanam tetap sama, dan ia mengesahkan anda untuk semua projek yang boleh dicapai akaun itu.

UI pula memberi gambaran alamat ini jauh lebih sempit daripada hakikat sebenar. Sebelum Aikido menghubungi GitLab, halaman settings menyatakan token itu "cannot be used to access any other data". Aikido lebih selesa memanggilnya fine-grained personal access token: skopnya merangkumi semua group dan projek anda, dengan kebenaran seperti Merge Request Create, Repository Update dan Protected Branch Update.

GitLab pula tidak menyemak siapa yang menghantar emel. Mana-mana peti mel di internet boleh menulis ke alamat itu, dan mesej yang diterima diproses seolah-olah datang daripada anda. Sesiapa yang memegang alamat itu sudah pegang authentication dan authorization serentak — tanpa pernah menyentuh inbox sebenar mangsa.

Dari lapor bug kepada tolak ke main

Aikido menunjukkan bagaimana token itu bertukar menjadi alat tolak kod menggunakan ciri merge request by email GitLab sendiri:

1. Tukar akhiran alamat daripada -issue kepada -merge-request. GitLab sekarang buka satu merge request, bukan issue.
2. Tulis git .patch dan letak nama branch sasaran pada baris subject emel.
3. Lampirkan patch itu dan hantar.
4. GitLab sapukan patch ke branch yang dinamakan — menciptanya jika belum wujud — dan perubahan itu jadi komit atas nama anda.
5. Kalau patch menyentuh .gitlab-ci.yml dan peranan anda membenarkan, GitLab menjalankan CI/CD job penyerang sebagai anda.

To:   [email protected]
Subject: main
Attachment: gitlab-ci-patch.diff

Tiada fork terlibat; merge request tidak boleh dihalakan ke salinan yang dikawal penyerang. Sebab itulah payload dibawa dalam patch yang dilampirkan, bukan dalam merge request itu sendiri. Sesiapa yang build daripada repository itu selepas itu akan menarik kod penyerang secara tidak langsung.

Aikido mengesahkan keseluruhan rantaian terhadap projek yang mereka kawal: tolak kod ke protected branch dalam repository private yang dilindungi IP allowlist, mengeluarkan source code daripada projek private yang sama, baca CI/CD variables dan secrets, capai confidential issues, dan guna CI_JOB_TOKEN yang terdedah dalam job untuk menyelongkar akaun lebih dalam.

Bypass yang menjadikannya lebih bahaya

Dua kawalan keselamatan yang ramai anggap penting sebenarnya tidak terpakai pada laluan emel.

Incoming email dikecualikan daripada IP restrictions. Dokumentasi GitLab menyatakannya secara terang-terangan, dan Aikido membuktikannya secara langsung: mereka mengunci satu projek private kepada satu alamat IP yang bukan milik mereka. Browser disekat, git clone ditolak — tapi emel merge request terus masuk, dan satu commit mendarat di main. Pasukan yang melukis sempadan di sekeliling projek dengan IP allowlist di tepi VPN tadi hanya menjaga pintu HTTP dan SSH; slot mel tetap terbuka luas.

Incoming email berfungsi tanpa 2FA. Dokumen admin GitLab menyatakan pengguna boleh menggunakan ciri incoming email tanpa melalui two-factor authentication dulu, walaupun pada instance yang mewajibkan 2FA. Alamat yang bocor sekali gus memintas kawalan yang sepatutnya melindungi sesi interaktif.

Apa yang sebenarnya menghadkan kerosakan

Dua kekangan menghalang ini daripada menjadi pengambilalihan akaun secara penuh:

• Token hanya membawa kebenaran anda. Tiada apa-apa dalam laluan emel yang menaikkan tahap kebenaran itu. Alamat yang bocor untuk akaun Guest hampir tidak berguna; yang untuk akaun Maintainer boleh sampai ke protected branches dan CI/CD secrets. Peranan anda yang menentukan sejauh mana risikonya.
• Routing memerlukan project path dan ID berangka. GitLab menentukan destinasi daripada path dan ID projek yang tertanam dalam alamat, jadi untuk menyasarkan projek tertentu penyerang juga perlu nilai itu. Projek public menerbitkan kedua-duanya; projek private memerlukan kebocoran berasingan (dan ID projek mudah diteka).

Tiada satu pun yang melegakan. Alamat-alamat ini sebenarnya sudah berada di luar sana: Aikido hanya membuang satu petang mencari dokumentasi awam dan menjumpai lebih kurang sedozen alamat hidup dalam README, contributing guides dan halaman sokongan — kebanyakannya diterbitkan dengan sengaja oleh maintainer yang memberitahu pengguna ke mana hendak hantar laporan bug, sebahagiannya dalam projek open-source yang popular. GitLab juga tidak mempunyai mekanisme untuk membatalkan token ini secara pukal atau memberitahu pengguna terjejas.

Tindak balas GitLab

Aikido mula-mula melaporkan kelakuan ini melalui HackerOne pada Mei 2026 dan ia ditutup sebagai intended behavior, kemudian memfailkan isu sulit (confidential) pada Jun. GitLab membalas dengan menggabungkan merge request 247431: baris "cannot be used to access any other data" dibuang, teks "and merge requests" ditambah pada UI, dan dokumentasi kini menyatakan incoming email memintas IP restrictions.

Yang tidak berubah: token masih tidak luput, GitLab masih tidak menyemak penghantar, dan tiada suis per-user untuk mematikan penciptaan issue atau merge request melalui emel. GitLab telah membuka work item 617883 untuk mengkaji sama ada emel diterima hanya daripada alamat yang disahkan milik pemilik akaun — itu baru dipertimbangkan, belum dilaksanakan. Pendirian GitLab, seperti yang Aikido sampaikan, ialah setiap token perlu dilayan sama seperti token lain; mana-mana credential yang bocor pasti membawa padah. Ringkasannya tepat, cuma ada satu tambahan yang tidak selesa: GitLab membina credential yang menjangkau setiap projek dalam akaun dan memintas IP restrictions, kemudian menampilkannya sebagai alamat emel yang sedia untuk disalin.

Apa yang anda patut buat

1. Putarkan incoming email token anda sekarang. Pautan reset ada di halaman personal access tokens. Reset itu membatalkan semua alamat projek sekaligus — maksudnya mana-mana alamat yang anda guna secara aktif akan terhenti berfungsi sehingga anda edarkan yang baharu.
2. Scan untuk alamat yang bocor. Periksa README, contributing guides dan halaman sokongan anda untuk alamat glimt-. Betterleaks, scanner open-source Aikido, kini mengesan semua varian token incoming email GitLab — yang berprefix glimt-, prefix tersuai, dan token yang dicipta sebelum prefix itu wujud.
3. Jangan layan IP allowlist GitLab sebagai sempadan keselamatan. Ia menyekat HTTP dan SSH, bukan emel masuk.
4. Menggunakan instance self-managed? Admin boleh mematikan incoming email untuk seluruh instance. Pengguna individu tiada suis — kalau anda yang urus instance itu, matikan melainkan anda benar-benar menggunakan ciri itu.

Ini peringatan daripada keluarga yang sama dengan bypass pin git yang dipanggil Plugin4Shell: keselamatan supply chain mati di jurang antara konvensyen. Kita layan alamat emel sebagai identifier yang memang dibuat untuk dikongsi, token sebagai credential, SSH sebagai satu-satunya pintu, dan main sebagai sesuatu yang dilindungi. Penemuan ini memecahkan empat andaian itu sekaligus dalam satu nafas. Putarkan token itu, kemudian pergi grep dokumentasi anda untuk string glimt- — carian yang sangat pendek, tapi kesannya panjang.

Sumber

• Aikido Security: Send GitLab an email, push to main
• The Hacker News: A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You
• GitLab: GitLab incoming email documentation
• GitLab: Merge requests by sending an email
• GitLab: GitLab work item 617883 — verify incoming email sender
• GitLab: GitLab merge request 247431 — align incoming email token capability across UI and docs