GitLab biedt een handige manier om via e-mail werkitems in te dienen: je klikt op een knop zoals “Email work item to this project” en krijgt een persoonlijk e-mailadres. Maar wat als dat adres in verkeerde handen valt? Volgens een melding van Aikido Security kan een gelekte GitLab issue-mail worden gebruikt als credential waarmee iemand code kan laten committen en zelfs CI/CD-jobs kan starten onder jouw identiteit.
In dit artikel leggen we uit wat er precies mis kan gaan, waarom dit verder gaat dan alleen bugrapporten, en welke praktische stappen je vandaag nog kunt nemen.
Wat is een GitLab issue-mail precies?
GitLab toont gebruikers per project een specifiek e-mailadres om via e-mail werkitems te melden. De werking is simpel: je stuurt een mail naar dat adres en GitLab zet de inhoud om in een nieuw item in dat project, met jou als auteur.
De kern van het probleem is dat het adres niet zomaar een “contactroute” is. De token in het midden van het adres is gekoppeld aan je account. Volgens de documentatie verloopt die token niet, dus een adres dat ooit uitlekt kan langdurig bruikbaar blijven.
Waarom een gelekte GitLab issue-mail gevaarlijk is
Het rapport beschrijft dat GitLab voor verschillende projecten adressen aanmaakt die er verschillend uitzien, maar waarbij dezelfde token wordt gebruikt. Dat betekent dat het adres, afhankelijk van je rechten, niet beperkt is tot één project.
Daarnaast handelt GitLab binnenkomende e-mail zonder te controleren wie de afzender werkelijk is. Elke mailbox die het adres kent, kan dus een bericht sturen en GitLab verwerkt dat alsof het van jou komt. Dat is niet alleen “een bug indienen”: het kan ook leiden tot acties met je machtigingen.
Van issue naar commit: het wordt ineens veel meer dan rapporteren
Aikido Security laat zien dat de functie niet alleen werkitems aanmaakt. Door een kleine wijziging in het e-mailadres en de manier waarop je de mail opzet, kan de bezitter het proces omzetten naar codewijzigingen via GitLab’s merge request via e-mail functionaliteit.
- Door het suffix aan te passen van -issue naar -merge-request opent GitLab een merge request-achtig proces in plaats van een issue.
- De e-mailonderwerpregel kan een doelbranch bevatten.
- De patch wordt als bijlage meegestuurd; GitLab past die toe op de branch (of maakt de branch als die nog niet bestaat).
- De wijziging landt vervolgens als commit op die branch, met auteurinformatie van jou.
Als je rechten het toelaten om naar relevante branches te pushen (inclusief main), dan kan de impact toenemen. En als de patch ook bijvoorbeeld het .gitlab-ci.yml-bestand aanpast, kan GitLab—bij voldoende rechten—CI/CD-jobs uitvoeren als jouw rol.
Wat bepaalt de impact voor jouw omgeving?
Niet elke tokenhouder kan automatisch “alles” doen. De grootste beperking is dat de token de machtigingen van de eigenaar weerspiegelt. Concreet betekent dit dat:
- Een gelekte issue-mail gekoppeld aan een Guest-account weinig oplevert, omdat die rol doorgaans nauwelijks toegang heeft.
- Een token bij een Maintainer kan wél verder gaan, omdat die rol vaak toegang heeft tot protected branches en mogelijk CI/CD-secrets.
Verder speelt het proces om überhaupt het juiste project te raken. GitLab bepaalt het doelproject op basis van het projectpad en een numeriek ID. Voor publieke projecten zijn pad en ID vaak zichtbaar. Voor private projecten is er een aparte lek nodig die het doel expliciet identificeert; wel is vermeld dat project-ID’s relatief makkelijk te raden kunnen zijn.
Geen IP-lockdown en mogelijk geen 2FA
Een extra zorgpunt is de manier waarop e-mailverwerking werkt. In het rapport staat dat inkomende e-mail niet onder dezelfde IP-restricties valt als andere toegangsroutes. Dat betekent dat een aanvaller ook van buiten een IP-allowlist kan starten.
Daarnaast wordt ook beschreven dat het proces via e-mail doorgaans twee-factor-authenticatie overslaat. GitLab zou aangeven dat e-mailgebaseerde features werken zonder 2FA, ook wanneer een GitLab-instantie 2FA verplicht.
In het beschreven voorbeeld werd een private project alleen voor een specifiek IPadres gelockt, maar accepteerde GitLab toch de merge request via e-mail. Daardoor kwam de commit alsnog op main terecht.
Voor wie geldt dit: GitLab.com en self-managed
Volgens Aikido’s bevindingen geldt de situatie voor elke GitLab.com account, omdat iedere account toegang heeft tot zo’n token/eadres voor incoming e-mail. Ook self-managed GitLab-instanties zijn volgens het rapport getroffen, zolang incoming email aanstaat (wat standaard ingeschakeld kan zijn op GitLab.com).
GitLab Dedicated lijkt niet direct te zijn geraakt, omdat GitLab de functionaliteit daar zou beperken tot self-managed en GitLab.com. Wel geeft het rapport aan dat Aikido Dedicated niet rechtstreeks kon testen.
Wat kun je nu doen (praktische acties)
Het is niet realistisch om het risico volledig “uit te zetten” voor andere personen—als een adres uitlekt, kan het misbruikt worden zolang de token geldig blijft. Maar je kunt wél je eigen exposure verlagen.
1) Reset je incoming e-mail token
GitLab biedt de mogelijkheid om het incoming e-mail token te resetten via de pagina met personal access tokens in je profiel. Dat resetproces vervangt het adres voor al je projecten tegelijk.
Let op: als je zelf actief e-mailadressen hebt gedeeld voor werkitems, stopt die integratie totdat je het nieuwe adres weer doorgeeft.
2) Controleer je documentatie op “gelekte” adressen
Ga je eigen repositories na. Het rapport noemt dat Aikido ongeveer een dozijn live adressen vond doordat ze in README’s, contributing guides en supportpagina’s stonden.
Veel van die adressen bleken te zijn geplaatst als bedoeld bugreportkanaal voor open-source projecten. Toch geldt: ook als het “bewust” gedeeld is, kan het in de praktijk breder terechtkomen dan je verwacht.
3) Zet incoming e-mail uit op self-managed GitLab
Als je een self-managed GitLab beheert, kan een administrator incoming email voor de hele instantie uitzetten. Het rapport stelt echter ook dat individuele gebruikers geen instelling hebben om alleen hun eigen e-mail-issue/merge-functionaliteit te stoppen.
Waarom GitLab de tekst heeft aangepast, maar het gedrag niet
Na het rapport zou GitLab de beschrijving rond de token hebben aangepast: de tekst vermeldt nu explicieter dat het adres issues en merge requests kan aanmaken. Tegelijk werd er eerder een zin verwijderd die stelde dat de token niet kon worden gebruikt om andere data te benaderen.
Belangrijk: volgens het rapport is het gedrag inhoudelijk niet veranderd. De token vervalt niet, GitLab controleert de afzender niet, en er is geen individuele schakelaar voor eindgebruikers.
Verwante risico’s om in dezelfde beveiligingshoek te bekijken
Dit incident laat vooral zien hoe belangrijk het is om “accounttokens” en automatische werkstromen te beschermen. Als je organisatie ook werkt met geautomatiseerde builds, CI/CD en externe triggers, zijn er parallelle aandachtspunten.
- Als je CI/CD gevoelig is voor misbruik van afhankelijkheden, kijk dan ook naar berichten over gecompromitteerde pakketten in pakketregisters, zoals gecompromitteerde MemTensor npm en PyPI pakketten.
- En omdat CI/CD bij wijzigingen in configuratiebestanden extra risico’s kan introduceren, is het nuttig om ook alert te zijn op kwetsbaarheden en exploits in andere CI- of build-gerelateerde omgevingen, bijvoorbeeld bij Ubuntu container escape via CVE-2026-80521.
Conclusie: behandel e-mailadressen als credentials
De kern van het verhaal is eenvoudig: een gelekte GitLab issue-mail is geen “onschuldig” bugmeldadres. Het functioneert als accountgebonden token, kan worden misbruikt zonder identiteitscheck, en kan via e-mail zelfs leiden tot patches, commits en CI/CD-activiteit onder jouw rol.
Door je token te resetten, je documentatie te controleren en—waar mogelijk—incoming e-mail in je GitLab-installatie te beperken, verklein je de kans dat een gelekt adres leidt tot echte schade. Neem dit mee in je standaard aanpak voor het beschermen van integraties en geautomatiseerde werkstromen.
Bron: https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html
