GitLab, il token "incoming" trasforma l'email in arma per la supply chain

23 settembre 2026 — Aikido Security ha pubblicato oggi la ricerca che documenta come l'indirizzo email "incoming" di GitLab, presentato dall'interfaccia come strumento per creare issue via email, contenga un token a lunga durata che consente a chiunque lo possieda di pushare codice su qualsiasi branch — main incluso — ed eseguire job CI/CD impersonando l'utente vittima. Il meccanismo bypassa sia le IP restrictions che l'autenticazione a due fattori. GitLab ha modificato il testo dell'interfaccia dopo la segnalazione, ma il comportamento è rimasto invariato.

Il credential che sembra un indirizzo email

La discrepanza centrale, documentata da Aikido Security, è tra il modello mentale proposto dall'interfaccia di GitLab e la realtà tecnica sottostante. All'utente viene presentato un indirizzo email "per creare issue in questo progetto". In realtà, come ha dimostrato il ricercatore, il token glimt- embedded nell'indirizzo è identico per tutti i progetti di un account. Aikido ha aperto la funzione "Email work item to this project" in cinque progetti diversi: GitLab ha restituito cinque indirizzi distinti, ma il token glimt- al loro interno era lo stesso, anche nei progetti privati.

Questo token è a lunga durata e non scade. Aikido lo definisce esplicitamente "a long-lived token tied to your account, and it never expires". La sua portata è l'intero account: progetti pubblici, privati, gruppi, e — se il ruolo della vittima lo permette — esecuzione di pipeline CI/CD.

Da issue a merge request: il percorso di attacco testato

La prova del concetto sviluppata da Aikido sfrutta una semplice alterazione del suffisso dell'indirizzo. Passando da -issue@... a -merge-request@... e allegando una patch, l'attaccante apre una merge request. GitLab applica la patch al branch specificato: "pushes to that branch if it exists and creates it if it doesn't", ha documentato il ricercatore. Il commit risultante è firmato con l'identità della vittima.

Se la patch modifica il file .gitlab-ci.yml e il ruolo dell'utente vittima consente l'esecuzione di job, GitLab esegue il pipeline come quell'utente. Aikido ha confermato questo percorso: "If the patch touches .gitlab-ci.yml and the victim's role allows it, GitLab runs the attacker's job". Il ricercatore ha inoltre verificato la lettura di variabili e secrets CI/CD da progetti privati, e l'esfiltrazione di codice sorgente da repository dietro IP allowlist.

Il bypass dei controlli perimetrali

Il meccanismo elude due controlli di sicurezza standard. Sul fronte delle IP restrictions, Aikido ha condotto un test con un progetto privato limitato a un singolo indirizzo IP non di proprietà del ricercatore. Il risultato: "GitLab blocked our browser and rejected our git clone commands. But it still accepted a merge request email." Il commit è stato applicato su main nonostante il blocco perimetrale.

Sul fronte 2FA, The Hacker News ha riportato che la documentazione ufficiale di GitLab indica come le feature incoming email "work without 2FA, even on instances that require it". L'email diventa così un canale privilegiato che ignora espressamente un controllo di autenticazione fondamentale.

"GitLab built a credential that reaches every project in the account and bypasses IP restrictions, then presented it as an email address."

Indirizzi pubblici, minaccia concreta

Aikido ha tracciato la superficie di attacco esposta. In un pomeriggio di ricerca, i ricercatori hanno trovato circa una dozzina di indirizzi email "incoming" pubblicati intenzionalmente in README, guide di contribuzione e pagine di supporto di progetti open source. Questi indirizzi, condivisi per ricevere segnalazioni di bug, sono credential attivi che permettono di scrivere nella supply chain del progetto e dell'account del maintainer.

La risposta di GitLab alla segnalazione rivela un gap di threat modeling. La prima segnalazione, inviata tramite HackerOne a maggio 2026, è stata chiusa come "intended behavior". Una seconda segnalazione via issue confidenziale è stata aperta a giugno 2026. Dopo queste segnalazioni, GitLab ha modificato il testo dell'interfaccia utente: ha aggiunto la dicitura "and merge requests" e rimosso la frase "cannot be used to access any other data". Il comportamento tecnico non è cambiato.

GitLab ha aperto un issue interno per valutare l'accettazione di email solo da indirizzi verificati, ma lo stato di questa misura è "under consideration": non implementata, non calendarizzata.

Cosa fare adesso

• Verificare l'esposizione: gli utenti con ruolo Maintainer o superiore devono controllare se il proprio indirizzo email "incoming" è stato pubblicato in documentazioni pubbliche, README o guide di contribuzione.
• Reset del token: dalla pagina personal access tokens è possibile rigenerare il token glimt-, invalidando gli indirizzi precedentemente esposti.
• Monitoraggio delle merge request via email: i team devono implementare controlli di code review obbligatori per merge request create tramite email, se questa feature è in uso nei progetti sensibili.
• Valutazione della feature: le organizzazioni self-managed devono verificare se incoming email sia abilitato e valutare la sua necessità rispetto al rischio documentato; su GitLab.com la feature è attiva di default.

Il pattern della produttività che diventa vector

Il caso GitLab non è un bug nel senso classico: non c'è un errore di implementazione da patchare. È piuttosto una feature di produttività — ricevere issue via email — che trasforma un identificatore apparentemente innocuo in un credential con privilegi impliciti e incontrollabili. Il vendor ha scelto di ridefinire l'etichetta dell'interfaccia piuttosto che il modello di autorizzazione.

Per le aziende che usano GitLab, il punto critico è che ogni utente con permessi elevati rappresenta un nodo di rischio supply chain se il suo indirizzo email token viene esposto. Per il settore, il pattern è più ampio: funzionalità progettate per ridurre friction che finiscono per sovvertire i controlli di sicurezza standard. Quando l'email "per creare issue" può scrivere su main, il problema non è tecnico ma di allineamento tra aspettative utente e architettura di autorizzazione.

Fonti

• https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html
• https://www.rescana.com/post/active-exploitation-alert-critical-gitlab-vulnerability-cve-2026-19478-targeted-within-24-hours-of-disclosure
• https://tech-insider.org/gitlab-cve-2026-19478-cvss-9-4-exploit-2026/
• https://github.com/hackeremmen/gitlab-exploit
• https://www.aikido.dev/blog/gitlab-email-push-to-main
• https://tech-insider.org/gcp-workload-identity-federation-setup-2026/
• https://nvd.nist.gov/vuln/detail/CVE-2026-19478
• https://support.github.com/
• https://about.gitlab.com/releases/2026/08/19/security-release-gitlab-19-2-4-released/
• https://advisories.gitlab.com/
• https://github.com/hackeremmen/gitlab-exploit/issues

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti