In questo articolo
Se la tua azienda esegue GitLab su un proprio server, aggiornalo oggi. Il 12 ottobre 2026 GitLab ha rilasciato una patch di sicurezza critica che corregge 24 vulnerabilità. La peggiore, CVE-2026-97229, ha ricevuto il punteggio di gravità più alto possibile: 10 su 10. Permette a chi non ha un account sul tuo server di eseguirvi il proprio codice. È coinvolto ogni server con le versioni 19.2 precedenti alla 19.2.8, 19.3 precedenti alla 19.3.5 o 19.4 precedenti alla 19.4.2. L'unica soluzione indicata da GitLab è l'aggiornamento alla 19.4.2, 19.3.5 o 19.2.8. Se usi il servizio cloud GitLab.com, non devi fare nulla.
Che cos'è GitLab e perché dovrebbe interessare a un imprenditore?
GitLab è il luogo in cui il tuo team tecnico conserva il codice sorgente dei tuoi sistemi e delle tue app, e dove le nuove versioni vengono compilate e distribuite ai tuoi server. Molte aziende lo eseguono su un server interno invece che sul servizio cloud, per mantenere codice e dati all'interno dell'organizzazione. Quel server di solito contiene più di quanto il titolare immagini: il codice sorgente completo, le password dei database, le chiavi che ti collegano ai gateway di pagamento e ai servizi pubblici, e il permesso di distribuire sui server usati dai tuoi clienti. Chi lo controlla può leggere tutto questo e può modificare il tuo codice prima che arrivi ai tuoi clienti.
Che cosa ha annunciato esattamente GitLab?
Secondo l'annuncio ufficiale della patch di GitLab, la falla si trova nella parte che elabora le espressioni regolari all'interno delle impostazioni delle pipeline di build e deploy (CI/CD). Un'espressione regolare è un breve testo che descrive uno schema di ricerca. L'annuncio afferma che la falla potrebbe consentire a un utente non autenticato di eseguire codice arbitrario sul server GitLab tramite un'espressione regolare appositamente costruita, a causa di una validazione insufficiente di tali espressioni. Un ricercatore l'ha segnalata tramite il programma di bug bounty di GitLab su HackerOne.
L'annuncio non dice che la falla sia stata sfruttata. Ma un punteggio di 10 significa che può essere sfruttata via internet, senza password e senza l'aiuto di alcun dipendente. Gli attaccanti di solito iniziano a cercare falle come questa pochi giorni dopo la pubblicazione di una correzione, perché la correzione stessa indica dove si trova la debolezza.
Cos'altro contiene la patch?
La stessa patch corregge altre 23 vulnerabilità, cinque delle quali classificate come alte:
- Un'iniezione di script malevoli (XSS) nell'evidenziazione della sintassi, con punteggio 8,7.
- Una falla di autorizzazione nella creazione delle pipeline, con punteggio 8,5.
- Un'espressione regolare troppo permissiva che riguarda l'accesso ai file, con punteggio 8,2.
- Una falla di autorizzazione nelle policy di esecuzione delle pipeline nell'edizione a pagamento, con punteggio 7,7.
- Una falla di prompt injection nell'agente di IA GitLab Duo nell'edizione a pagamento, con punteggio 7,3.
Quindi le versioni precedenti alla 19.2, non colpite dalla falla critica, non sono necessariamente sicure. La politica ufficiale di manutenzione di GitLab stabilisce che le correzioni di sicurezza vengono riportate solo sulla versione attuale e sulle due versioni mensili precedenti. Un server con una versione più vecchia non riceve più alcuna correzione di sicurezza e va comunque aggiornato.
Chi deve intervenire?
- Utenti del cloud GitLab.com: nulla da fare; GitLab afferma che il servizio esegue già la versione corretta.
- Clienti di GitLab Dedicated: nulla da fare neanche per loro, secondo l'annuncio.
- Chiunque esegua GitLab su un proprio server: aggiorni immediatamente. È la raccomandazione esplicita di GitLab per ogni installazione autogestita.
- Chiunque non sappia dove gira il proprio GitLab: chiedi oggi al tuo team o al fornitore che ha sviluppato i tuoi sistemi. Molti server interni sono stati configurati da un fornitore precedente e poi dimenticati.
Passi pratici per questa settimana
- Individua la versione: chiedi al tuo responsabile tecnico di aprire la pagina Aiuto in GitLab, leggere il numero di versione mostrato e confrontarlo con i numeri indicati sopra.
- Pianifica l'aggiornamento oggi, non a fine mese: secondo l'annuncio di GitLab, un server a nodo singolo resta offline durante la patch finché non terminano le migrazioni del database, mentre le configurazioni multi-nodo possono essere aggiornate senza interruzioni se si segue la procedura corretta senza tempi di inattività. Un'ora di fermo fuori dall'orario di lavoro costa molto meno di un server compromesso.
- Se sei sulla 19.3: passa direttamente alla 19.3.5, non alla 19.3.4. L'annuncio segnala che la 19.3.4 aveva un bug che interessava le pagine delle merge request quando l'integrazione Ona era attiva, corretto nella 19.3.5.
- Riduci l'esposizione a internet: se nessuno al di fuori dell'azienda deve raggiungere il tuo server GitLab, fai in modo che accetti connessioni solo dalla rete aziendale o tramite una VPN. Non sostituisce la patch, ma restringe la porta la prossima volta.
- Controlla dopo la patch: verifica gli utenti, le chiavi e i token di accesso creati di recente. Se compare qualcosa che nessuno riconosce, cambia le password e le chiavi memorizzate sul server.
I passaggi di aggiornamento per ogni metodo di installazione si trovano nella guida ufficiale all'aggiornamento di GitLab.
Il punto di vista di Origami
Usiamo GitLab ogni giorno, dato che i nostri repository si trovano lì, quindi seguiamo i suoi annunci di sicurezza con la stessa attenzione che dedichiamo alle nostre fatture. La lezione va oltre GitLab: ogni sistema che gestisci in proprio per tenere i dati in casa comporta il dovere di aggiornarlo il giorno stesso in cui arriva una correzione. Il problema che vediamo più spesso non è quella scelta in sé, ma l'assenza del nome di chi è responsabile degli aggiornamenti. Un server configurato da un fornitore tre anni fa, di cui nessuno sa chi si occupi, è la prima cosa che un attaccante cerca. Abbiamo detto lo stesso a proposito della falla dei negozi Magento: applicare la patch non basta se arriva tardi. Se hai bisogno di qualcuno che esamini i tuoi server o si occupi dei loro aggiornamenti, contattaci.
Fonti
Domande frequenti
La mia azienda è colpita dalla nuova falla di GitLab CVE-2026-97229?
Sei coinvolto se esegui GitLab sul tuo server con la versione 19.2 precedente alla 19.2.8, la 19.3 precedente alla 19.3.5 o la 19.4 precedente alla 19.4.2. Secondo GitLab, gli utenti del cloud GitLab.com e i clienti di GitLab Dedicated non devono fare nulla.
A quale versione devo aggiornare?
Alla 19.4.2, 19.3.5 o 19.2.8, le versioni che GitLab ha rilasciato il 12 ottobre 2026. Se sei sulla 19.3, passa direttamente alla 19.3.5, perché la 19.3.4 aveva un bug che la 19.3.5 corregge.
GitLab resta offline durante l'aggiornamento?
Un server a nodo singolo resta offline durante la patch finché non terminano le migrazioni del database, mentre le installazioni multi-nodo possono essere aggiornate senza interruzioni seguendo la procedura documentata di GitLab senza tempi di inattività. Pianificalo fuori dall'orario di lavoro nello stesso giorno.
Il nostro server usa una versione precedente alla 19.2. Siamo al sicuro?
Non siete colpiti da questa specifica falla critica, ma la politica di GitLab limita le correzioni di sicurezza alla versione attuale e alle due versioni mensili precedenti, quindi una versione più vecchia non riceve più alcuna correzione di sicurezza e va aggiornata.
Segua Origami su Google
Aggiunga Origami tra le fonti preferite e i nostri articoli le compariranno per primi nella Ricerca Google e nelle notizie principali.








