Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Un punteggio CVSS di 10,0 su 10, il massimo possibile, per una falla che non richiede né credenziali né interazione da parte delle vittime. Il 21 ottobre 2026 GitLab ha rilasciato le patch per CVE-2026-110264, una vulnerabilità critica che può consentire a un aggressore non autenticato di eseguire codice arbitrario da remoto sul server. Colpisce le installazioni self-managed, sia Community Edition (CE) sia Enterprise Edition (EE), a partire dalla versione 7.0. Per chi gestisce un'istanza locale, il messaggio è semplice: aggiornare subito.
La causa è un integer overflow nel compilatore delle espressioni regolari, innescato dall'elaborazione di una regex costruita ad arte. Secondo l'advisory ufficiale, l'esecuzione di codice arbitrario è possibile «in determinate condizioni», che però GitLab non descrive nel dettaglio. È una scelta comprensibile: i dettagli delle segnalazioni di sicurezza nell'issue tracker diventano pubblici, di norma, 90 giorni dopo la release che contiene la correzione.
Il vettore CVSS racconta comunque molto: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Tradotto:
Più di così, la metrica non può dare.
Un indizio sul componente coinvolto arriva dal nome di una delle regole di rilevamento pubblicate da GitLab: Onigmo native worker crash. Onigmo è la libreria di espressioni regolari usata da Ruby, il linguaggio su cui poggia GitLab. Il nome lascia pensare che il problema risieda lì, anche se le fonti non lo affermano esplicitamente.
La falla è stata segnalata dal ricercatore joaxcar tramite il programma di bug bounty di GitLab su HackerOne.
Colpisce soprattutto l'estensione del problema. L'intervallo delle versioni vulnerabili parte da GitLab 7.0. Diverse testate, tra cui la francese Frandroid, parlano di tutte le versioni pubblicate dal 2014, e quindi di circa dodici anni di rilasci. L'advisory ufficiale, però, si limita a indicare la 7.0 come punto di partenza, senza riferimenti temporali.
In pratica, qualunque istanza self-managed non aggiornata alle nuove versioni è esposta. E un server GitLab non è una macchina qualsiasi. Ospita i repository, gestisce le pipeline CI/CD e custodisce token, chiavi di deploy e variabili con i segreti degli ambienti di produzione. L'advisory parla di esecuzione di codice sul server. Per un'infrastruttura del genere, però, è facile immaginare dove possa arrivare un aggressore che ne prenda il controllo.
Al momento GitLab non segnala sfruttamenti in corso né casi di compromissione accertati. Chi gestisce GitLab.com non deve fare nulla: la piattaforma gira già sulla versione corretta. Sono già coperti anche i tenant GitLab Dedicated con build 19.3.5-internal0 e 19.4.2-internal0 o successive. Attenzione a non confondere queste build interne con le release pubbliche dalla numerazione simile.
Le release correttive sono:
GitLab ha inoltre portato la correzione su quattro rami più vecchi:
C'è un dettaglio che può ingannare anche gli amministratori più diligenti. Questo advisory è distinto da quello del 12 ottobre 2026, dedicato a CVE-2026-97229. Chi in quell'occasione ha installato le release pubbliche 19.4.2, 19.3.5 o 19.2.8 resta sotto le nuove soglie di sicurezza e deve aggiornare di nuovo. Aver applicato quella patch non basta.
Le note di rilascio segnalano migrazioni del database nelle versioni 19.4.3 e 19.3.6, più migrazioni post-deploy nella 19.4.3. Sulle installazioni a nodo singolo l'aggiornamento comporta un fermo del servizio. Le configurazioni multi-nodo possono invece evitarlo, purché si segua correttamente la procedura zero-downtime. Se l'istanza è molto indietro, la documentazione sul percorso di aggiornamento impone tappe intermedie e il completamento delle migrazioni in background prima di procedere al salto successivo.
Per chi vuole capire se qualcuno ha già provato a sfruttare la falla, GitLab ha pubblicato due regole di rilevamento per i clienti self-managed: Onigmo native worker crash e Org mode render error burst. Vanno lette come strumenti di verifica, non come la conferma di una campagna attiva.
La release corregge in tutto 12 vulnerabilità. Tra le più serie c'è CVE-2026-15723 (CVSS 8,2). Un attaccante autenticato può impossessarsi di un account LDAP esistente quando sono attivi sia OmniAuth SAML sia il collegamento automatico con LDAP. Il difetto nasce da una sanitizzazione insufficiente dell'input durante la ricerca dell'indirizzo email su LDAP, usata per collegare le identità, e non richiede alcuna azione da parte del titolare dell'account.
CVE-2026-112212 (CVSS 7,5) riguarda invece un cache poisoning negli endpoint di discovery OAuth/OIDC. In determinate condizioni, un aggressore non autenticato può manipolare un documento di discovery condiviso e dirottare alcuni flussi verso un server sotto il suo controllo. Le restanti correzioni toccano, tra l'altro, le restrizioni dei token GraphQL, l'esposizione di credenziali interne, la divulgazione di metadati di milestone private e di titoli di issue riservate, le policy di approvazione e i controlli amministrativi sulle funzioni AI.
Con un RCE da 10,0 senza autenticazione nello stesso pacchetto, la priorità di questo aggiornamento non è in discussione. Ogni istanza GitLab raggiungibile da Internet e ferma su una versione precedente alle soglie indicate va considerata a rischio finché non viene aggiornata.
Fonti: thehackernews.com, easternherald.com
Nessuno ha ancora commentato.
![[Agg: update ora disponibile] Allarme rosso per PHP: due vulnerabilità critiche consentono l'hack immediato di qualsiasi sito (PHP2Shell) (aggiornato: 22 ottobre 2026, ore 16:21)](https://turbolab.it/immagini/reg/6/global-php-cyber-attack-28250.avif)
