GitLab ha rilasciato il 17 agosto una patch d'emergenza per CVE-2026-19478, una falla di code injection con punteggio CVSS 9.4 che consente a un attaccante non autenticato di modificare o cancellare progetti pubblici e di riscriverne lo stato. Due giorni dopo la divulgazione, la rete di honeypot Attacker Eye di watchTowr ha registrato i primi tentativi di sfruttamento reale.

È una di quelle vulnerabilità che, nella pratica, valgono più del loro punteggio: non serve un account, non serve interazione dell'utente, non serve una configurazione esotica. Basta una richiesta HTTP verso l'endpoint GraphQL.

I fatti

Il problema nasce dalla gestione impropria di una direttiva GraphQL. Le direttive sono annotazioni che modificano il comportamento di una query: GitLab non validava correttamente il loro contenuto, e questo permette di iniettare codice che viene eseguito nel contesto dell'applicazione.

Le conseguenze descritte da chi ha analizzato la falla non riguardano l'esecuzione di comandi sul sistema operativo, ma qualcosa che per un'organizzazione può essere altrettanto grave:

  • cancellazione integrale di repository pubblici;
  • falsificazione di record di merge, cioè far apparire come integrata una correzione che non è mai stata applicata;
  • ban dei manutentori di un progetto, con conseguente perdita di controllo.

watchTowr ha dichiarato di aver riprodotto la vulnerabilità in pochi minuti, partendo dall'advisory pubblico di GitLab e dal diff della patch. È il classico caso di patch-diffing: la correzione stessa diventa la mappa che porta all'exploit, ed è il motivo per cui la finestra fra rilascio e sfruttamento si è ridotta a 48 ore.

Versioni interessate

La falla riguarda GitLab Community Edition ed Enterprise Edition:

  • dalla 18.2 fino alla 18.11.10
  • dalla 19.0 fino alla 19.0.7
  • dalla 19.1 fino alla 19.1.5
  • dalla 19.2 fino alla 19.2.3

Le versioni corrette sono 18.11.11, 19.0.8, 19.1.6 e 19.2.4. Le istanze su GitLab.com sono già state aggiornate dal fornitore: il problema riguarda le installazioni self-managed, cioè proprio quelle che molte aziende italiane hanno scelto per tenere il codice in casa.

Cosa significa per le aziende italiane

Qui c'è un'ironia che vale la pena raccogliere. Chi ha portato GitLab on-premise lo ha spesso fatto per una ragione di sovranità del dato: il codice sorgente è proprietà intellettuale, non deve stare sul cloud di un fornitore estero. È una scelta legittima e in molti casi corretta. Ma comporta un obbligo che viene sottovalutato: la responsabilità della patch passa interamente a te, e le patch d'emergenza non aspettano la finestra di manutenzione del trimestre.

Nel tessuto produttivo italiano GitLab self-managed è diffusissimo: software house, system integrator, reparti IT interni di manifatturiero e utility, fornitori della Pubblica Amministrazione. Sono realtà dove l'istanza GitLab è spesso stata installata anni fa da una persona che nel frattempo ha cambiato ruolo, e dove l'aggiornamento è visto come un rischio operativo più che come una misura di sicurezza.

Il rischio concreto che vedo, in ordine di gravità reale:

1. Perdita di integrità, non solo di disponibilità. La cancellazione di un repository è dolorosa ma visibile: te ne accorgi subito e, se hai i backup, recuperi. La falsificazione di un record di merge è molto peggio, perché è silenziosa. Se un attaccante fa apparire come integrata una patch di sicurezza che non è mai stata applicata, la tua tracciabilità è compromessa. Chi lavora con software che finisce in prodotti regolamentati — dispositivi medici, automotive, macchinari industriali sotto Direttiva Macchine, componenti soggetti al Cyber Resilience Act — deve poter dimostrare quale codice è stato costruito e quando. Un log di merge inaffidabile fa saltare quella dimostrazione.

2. Effetto a valle sui clienti. Se sei una software house che sviluppa per terzi, la tua istanza GitLab è un nodo di supply chain. Un attaccante che riscrive lo stato di un progetto pubblico può inserirsi in una catena che finisce nei sistemi dei tuoi clienti. Per i soggetti NIS2 questa è la definizione manuale del rischio da fornitore ICT che l'art. 24 del D.Lgs. 138/2024 impone di gestire contrattualmente.

3. Esposizione inutile. Molte istanze GitLab self-managed sono raggiungibili da Internet senza una reale necessità: servono a tre sviluppatori che potrebbero benissimo passare da VPN. L'esposizione è un'abitudine, non una scelta architetturale.

Il contesto normativo

Per i soggetti in perimetro NIS2 la vulnerabilità tocca due obblighi distinti. Il primo è la gestione delle vulnerabilità e degli aggiornamenti, esplicitamente citata fra le misure minime. Il secondo, meno ovvio, è la notifica: se lo sfruttamento porta a una compromissione con impatto significativo sui servizi, scatta la pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza, seguita dalla notifica entro 72 ore. Il conteggio parte da quando l'organizzazione viene a conoscenza dell'incidente, non da quando ha finito di analizzarlo: chi non ha un processo di triage rapido arriva sistematicamente tardi.

Se nei repository compromessi ci sono dati personali — succede più spesso di quanto si ammetta, fra dump di test, file di configurazione e credenziali di servizio — si apre in parallelo il fronte GDPR, con le 72 ore dell'art. 33 verso il Garante.

Vale anche un'osservazione che riguarda DORA per il settore finanziario: un'istanza GitLab su cui si sviluppano applicazioni core è, a tutti gli effetti, un asset ICT critico. Il registro delle informazioni e la classificazione degli incidenti devono tenerne conto.

Cosa fare subito

  • Aggiorna immediatamente alla versione 18.11.11, 19.0.8, 19.1.6 o 19.2.4 a seconda del ramo in uso. È una patch d'emergenza con sfruttamento confermato: non è un aggiornamento da pianificare, è da fare oggi.
  • Censisci le istanze esposte. Verifica quali GitLab della tua organizzazione rispondono da Internet. Includi le installazioni dimenticate: ambienti di staging, istanze di progetti chiusi, macchine di reparti che si sono gestiti da soli.
  • Se non puoi patchare subito, limita l'endpoint GraphQL. Blocca /api/graphql a livello di reverse proxy o WAF per il traffico non autenticato, oppure metti l'intera istanza dietro VPN. È una mitigazione temporanea, non una soluzione.
  • Verifica se hai progetti pubblici attivi. La falla colpisce i progetti accessibili pubblicamente: se non ti servono, portali a internal o private. Molte istanze hanno progetti pubblici per dimenticanza, non per scelta.
  • Controlla i log alla ricerca di richieste POST verso l'endpoint GraphQL provenienti da fonti non autenticate, con particolare attenzione al periodo dal 17 agosto in poi.
  • Verifica l'integrità dello storico. Confronta gli hash dei commit e i record di merge dei progetti critici con i cloni locali degli sviluppatori e con i backup precedenti al 17 agosto. È l'unico modo per accorgersi di una manipolazione silenziosa.
  • Verifica i backup prima di averne bisogno. Un backup di GitLab che non è mai stato testato in restore, statisticamente, non è un backup.
  • Rivedi la lista dei manutentori dei progetti importanti: un ban non autorizzato è un indicatore di compromissione facile da controllare e facile da non notare.

In sintesi

CVE-2026-19478 è la conferma di un pattern che ormai è la norma e non l'eccezione: fra la pubblicazione di una patch e il primo tentativo di sfruttamento passano ore o pochi giorni, perché il patch-diffing è diventato routine per chi attacca. Le organizzazioni che ragionano ancora in termini di finestre di aggiornamento mensili stanno giocando una partita con regole scritte dieci anni fa.

Per chi gestisce un GitLab self-managed la domanda operativa non è "quando aggiorno", ma "quanto tempo mi serve per aggiornare quando devo farlo in giornata". Se la risposta è più di 48 ore, il problema non è questa CVE: è il processo.