← Tutti gli articoli

La vulnerabilità di GitLab potrebbe consentire RCE senza autenticazione

La vulnerabilità di GitLab potrebbe consentire RCE senza autenticazione

La vulnerabilità CVE-2026-110264 di GitLab potrebbe consentire remote code execution (RCE) senza autenticazione, il che significa che un aggressore potrebbe riuscire a eseguire comandi su un server self-managed senza prima effettuare l'accesso. GitLab ha assegnato alla vulnerabilità un punteggio di 10.0 secondo il Common Vulnerability Scoring System (CVSS), il valore massimo della scala, e ha pubblicato le correzioni il 21 ottobre. Ogni release di GitLab a partire dalla versione 7.0, apparsa nel 2014, è interessata, a meno che non sia stata aggiornata a una delle nuove versioni corrette.

La vulnerabilità deriva da un integer overflow, un errore che si verifica quando un numero supera lo spazio riservato per memorizzarlo, mentre il motore Onigmo integrato in Ruby compila una regular expression appositamente costruita. Una regular expression è un pattern utilizzato dal software per trovare o elaborare testo corrispondente. GitLab include Onigmo nei propri pacchetti e applica patch al motore nelle sue build. Poiché il componente interessato è distribuito con GitLab sin dalla versione 7.0, l'esposizione si estende a un numero di branch superiore rispetto alla consueta finestra di supporto per la sicurezza dell'azienda.

GitLab afferma che lo sfruttamento sia possibile soltanto in determinate condizioni, ma non ha reso noto quali siano. Di conseguenza, gli amministratori non possono stabilire dalla sola configurazione se un'installazione possa essere attaccata. L'avviso non indica alcun workaround temporaneo, quindi l'installazione di una release corretta è l'unica protezione certa individuata da GitLab.

La versione di destinazione richiesta dipende dal branch attualmente installato. I sistemi con una versione 19.5 precedente alla 19.5.1 devono passare alla 19.5.1. Le installazioni della versione 19.4 precedenti alla 19.4.3 richiedono la 19.4.3, mentre quelle della versione 19.3 precedenti alla 19.3.6 richiedono la 19.3.6. Gli amministratori che eseguono una versione 19.2 precedente alla 19.2.9 devono installare la 19.2.9; quelli con una versione 19.1 precedente alla 19.1.9 devono installare la 19.1.9; quelli con una versione 19.0 precedente alla 19.0.10 devono installare la 19.0.10. Tutte le release interessate dalla 7.0 alla 18.11 devono essere aggiornate alla 18.11.13.

Quattro di queste correzioni non rientrano nella normale politica di manutenzione di GitLab. Di norma, l'azienda applica patch alla release mensile corrente e alle due release immediatamente precedenti, che in quel momento erano la 19.5, la 19.4 e la 19.3. A causa della gravità di CVE-2026-110264, GitLab ha inoltre effettuato il backport della correzione alle versioni 18.11.13, 19.0.10, 19.1.9 e 19.2.9.

Gli amministratori che hanno installato gli aggiornamenti di sicurezza di GitLab del 12 ottobre devono comunque intervenire. Quelle patch precedenti riguardavano soltanto le versioni 19.2 e successive, tramite le release 19.2.8, 19.3.5 e 19.4.2. Le correzioni del 21 ottobre si trovano ciascuna un patch level sopra tali versioni, quindi un server aggiornato il 12 ottobre può essere ancora vulnerabile a CVE-2026-110264.

Soltanto le installazioni self-managed di GitLab devono essere aggiornate dai clienti. GitLab.com utilizza già una versione corretta. Anche gli ambienti GitLab Dedicated che utilizzano le release interne 19.3.5-internal0 e 19.4.2-internal0, o qualsiasi versione successiva, contengono la correzione.

GitLab non ha segnalato prove che CVE-2026-110264 sia stata sfruttata in attacchi. Al 22 ottobre, era inoltre assente dal catalogo delle vulnerabilità note sfruttate della U.S. Cybersecurity and Infrastructure Security Agency. GitLab ha comunque pubblicato due regole per esaminare i logs dell'applicazione alla ricerca di possibili tentativi. Denominate "Onigmo native worker crash" e "Org mode render error burst", le regole sono disponibili tramite il framework open-source TLDR di GitLab e utilizzano Sigma, un formato standard per descrivere attività sospette nei logs.

Questa è la quarta vulnerabilità di code execution nel motore di regular expression di GitLab segnalata dallo stesso ricercatore nell'arco di un mese, nonché la prima delle quattro a interessare release precedenti alla 19.2. Il 12 ottobre GitLab ha corretto CVE-2026-97229, un'altra vulnerabilità integer overflow senza autenticazione con punteggio 10.0, nelle versioni 19.2.8, 19.3.5 e 19.4.2. Il 23 settembre ha corretto CVE-2026-93577 e CVE-2026-89078. Entrambe hanno ricevuto un punteggio di 9.9 e richiedevano che l'aggressore disponesse di un account con accesso effettuato. Queste tre vulnerabilità precedenti non interessavano le versioni anteriori alla 19.2.

La release del 21 ottobre risolve complessivamente 11 problemi di sicurezza, tra cui una vulnerabilità critica e dieci problemi di gravità alta, media o bassa. Una delle ulteriori vulnerabilità di gravità alta, CVE-2026-15723, ha un punteggio di 8.2 e potrebbe consentire a un utente autenticato di assumere il controllo di un altro account. Si applica soltanto quando un amministratore ha abilitato l'account linking automatico sia per Security Assertion Markup Language (SAML) sia per Lightweight Directory Access Protocol (LDAP), due tecnologie utilizzate per collegare le identità di accesso.

Un altro problema di gravità alta, CVE-2026-112212, è una vulnerabilità di cache-poisoning con punteggio 7.5. Interessa gli endpoint OAuth e OpenID Connect di GitLab, che partecipano all'accesso e all'autorizzazione degli account. Nelle configurazioni che utilizzano una shared cache, un aggressore potrebbe reindirizzare determinati flussi di accesso verso un server sotto il proprio controllo.

La pianificazione dell'aggiornamento è particolarmente importante per gli amministratori di sistemi single-node. GitLab afferma che le versioni 19.4.3 e 19.3.6 includono modifiche al database che vengono eseguite durante l'installazione, causando downtime su un server composto da un solo node fino al completamento di tali modifiche. I deployment multi-node possono utilizzare la procedura di zero-downtime upgrade di GitLab. Per le organizzazioni che necessitano di assistenza nella gestione di questo tipo di rischio infrastrutturale, AEU-I offre servizi IT, infrastrutturali e di consulenza incentrati anzitutto sulla sicurezza.

Gli operatori di sistemi self-managed devono individuare il proprio branch esatto, selezionare la release corretta corrispondente e tenere conto dell'eventuale downtime necessario. L'assenza di sfruttamento osservato non modifica l'intervallo delle versioni interessate né elimina la necessità di installare l'aggiornamento del 21 ottobre.

Disponibile anche in: EnglishDeutschShqip