Het privé-e-mailadres dat GitLab u geeft voor het indienen van problemen per e-mail is een referentie. Iedereen die het krijgt, kan een patch e-mailen die GitLab in jouw naam heeft vastgelegd, naar elke branch waar je naartoe kunt pushen, inclusief main, en kan CI/CD-taken starten die net als jij draaien.
GitLab toont elke gebruiker dit adres achter een knop met het label ‘E-mail werkitem naar dit project’. E-mail die ernaar wordt verzonden, opent een probleem in dat project, dat door u is geschreven.
De string in het midden van het adres is een token dat aan je account is gekoppeld en volgens de documentatie van GitLab verloopt deze niet.
Het adres lijkt bij één project te horen. Dat is niet het geval. Aikido Security, dat het gedrag rapporteerde, ontdekte dat de adressen die GitLab aanmaakt voor de verschillende projecten van een gebruiker allemaal hetzelfde token delen, en dat het token van toepassing is op elk project dat het account kan openen, openbaar of privé.
GitLab controleert niet wie de e-mail heeft verzonden. Elke mailbox kan naar het adres schrijven, en GitLab reageert op het bericht alsof het van jou komt. Degene die het adres bezit, kan zowel als u inloggen als met uw toestemming handelen, zonder ooit uw mailbox aan te raken.
Het adres doet meer dan alleen bugs archiveren. Aikido liet zien hoe een houder er een manier van maakt om code vast te leggen, met behulp van GitLab’s eigen samenvoegverzoek per e-mailfunctie:
- Wijzig het adresachtervoegsel van -issue in -merge-request. GitLab opent vervolgens een samenvoegverzoek in plaats van een probleem.
- Schrijf een patch en plaats de naam van een doelvertakking in de onderwerpregel van de e-mail.
- Bevestig de patch en verzend deze. GitLab past de patch toe op die branch, en maakt de branch aan als deze nog niet bestaat.
- De wijziging komt terecht als een commit op die branch, die door jou is geschreven. Als het een branch is waar je naartoe kunt pushen, omvat dat ook de main.
- Als de patch het .gitlab-ci.yml-bestand van het project bewerkt en uw rol dit toestaat, voert GitLab de taak van de aanvaller uit zoals u.
Het samenvoegverzoek zelf kan niet gericht zijn op een kopie van het project dat de aanvaller beheert. Daarom bevat de bijgevoegde patch, en niet het samenvoegverzoek, de code.
Twee dingen zorgen ervoor dat dit niet erger wordt. Het token heeft alleen uw eigen machtigingen, dus hoe ver een aanvaller komt, hangt af van uw rol. Een gelekt adres voor een gastaccount is vrijwel nutteloos, terwijl een adres voor een beheerder toegang heeft tot beveiligde branches en CI/CD-geheimen.
Voor het bereiken van een project is ook meer nodig dan alleen het adres. GitLab berekent het doel op basis van het projectpad en de numerieke ID, dus een aanvaller die een bepaald project wil, heeft zowel het pad en de ID van dat project als het token nodig. Publieke projecten publiceren beide. Een privéproject heeft een afzonderlijk lek met een naam, hoewel de project-ID’s van GitLab gemakkelijk te raden zijn.
Omdat inkomende e-mail is vrijgesteld van IP-beperkingen, kan de aanval afkomstig zijn van buiten een IP-toelatingslijst. In de documentatie van GitLab staat dat inkomende e-mail niet onderworpen is aan IP-beperkingen.
Aikido heeft een privéproject vergrendeld op een enkel IP-adres dat niet het zijne was. GitLab blokkeerde zijn browser en weigerde een git-kloon, maar accepteerde de e-mail met het samenvoegverzoek en de commit belandde op main.
Hetzelfde pad slaat tweefactorauthenticatie over. In de documentatie van GitLab wordt opgemerkt dat functies voor inkomende e-mail werken zonder 2FA, zelfs op instanties die dit vereisen.
Elk GitLab.com-account heeft een van deze tokens, en dat geldt ook voor elk zelfbeheerd GitLab-exemplaar waarbij inkomende e-mail is ingeschakeld, wat de standaard is op GitLab.com.
GitLab Dedicated lijkt er geen last van te hebben, omdat GitLab de functie beperkt tot zelfbeheer en GitLab.com, maar Aikido zei dat het Dedicated niet rechtstreeks kon testen.
Wat te doen
U kunt niet voorkomen dat andere mensen deze functie gebruiken, maar u kunt wel een gelekt adres afsnijden.
- Reset uw token voor inkomende e-mail vanaf de pagina met persoonlijke toegangstokens in uw profiel. Door de reset wordt elk projectadres in één keer vervangen, dus een adres dat u actief gebruikt, stopt met werken totdat u het nieuwe uitdeelt.
- Blader door uw eigen README’s, bijdragende handleidingen en ondersteuningspagina’s voor een postadres. Aikido zei dat het op deze manier ongeveer een dozijn live-adressen heeft gevonden, waarvan de meeste met opzet zijn gepubliceerd als plaatsen om bugrapporten te verzenden, en een paar in veelgebruikte open-sourceprojecten.
- Op een zelfbeheerd exemplaar kan een beheerder binnenkomende e-mail uitschakelen voor het hele exemplaar. Er is geen instelling waarmee een individuele gebruiker e-mailproblemen kan uitschakelen of het maken van samenvoegverzoeken kan uitschakelen.
GitLab veranderde de tekst rond het token na het rapport van Aikido. De beschrijving zegt nu dat het adres problemen en samenvoegverzoeken kan veroorzaken, terwijl het voorheen alleen werkitems vermeldde, en GitLab verwijderde een regel waarin stond dat het token niet kon worden gebruikt om toegang te krijgen tot andere gegevens.
Het gedrag is niet veranderd. Het token verloopt nog steeds niet, GitLab controleert nog steeds niet wie de e-mail heeft verzonden en er is nog steeds geen schakelaar voor een individuele gebruiker om de functie uit te schakelen.
GitLab heeft een probleem geopend om te kijken naar het accepteren van deze e-mails alleen van een adres dat is geverifieerd bij de accounteigenaar, maar dit wordt overwogen en is nog niet van toepassing.
Aikido zei dat het het gedrag voor het eerst meldde via HackerOne in mei 2026, waar het werd gesloten als bedoeld gedrag, en vervolgens in juni een vertrouwelijke kwestie bij GitLab indiende. Het standpunt van GitLab, zoals Aikido het beschreef, is dat dit een token is zoals alle andere, en dat elk gelekt certificaat tot slechte resultaten leidt.
The Hacker News heeft contact opgenomen met GitLab en Aikido voor commentaar.
