GitLab a rischio RCE, Node.js e HTTP/3 aprono nuove falle nei server

🛡️ Executive Summary

• GitLab corregge CVE-2026-110264, vulnerabilità CVSS 10 che può consentire esecuzione di codice senza autenticazione e interessa versioni distribuite dal 2014.
• Node.js risolve CVE-2026-111497, scrittura fuori dai limiti di memoria nel decoder Brotli con potenziale RCE sulle tre linee supportate.
• FoxIO documenta vulnerabilità QPACK in sette implementazioni HTTP/3 su dieci, con amplificazione della memoria fino a circa 4.000 volte e possibili attacchi denial-of-service.

GitLab, Node.js e diverse implementazioni HTTP/3 affrontano vulnerabilità che interessano componenti fondamentali delle infrastrutture applicative e dei servizi web. GitLab ha corretto una falla CVSS 10 presente in release risalenti al 2014, Node.js ha distribuito aggiornamenti per un errore di memoria nel decoder Brotli capace di consentire esecuzione di codice remoto e FoxIO ha documentato una classe di attacchi contro QPACK che permette di esaurire le risorse dei server attraverso richieste compresse di dimensioni relativamente contenute. Le tre vicende presentano impatti differenti, ma evidenziano una debolezza architetturale comune: la gestione di input non attendibili all’interno di componenti software privilegiati o esposti alla rete può trasformare operazioni ordinarie di elaborazione in compromissioni o interruzioni del servizio.

GitLab corregge una falla CVSS 10 presente in dodici anni di versioni

La vulnerabilità più critica riguarda CVE-2026-110264, un integer overflow nel compilatore delle espressioni regolari utilizzato da GitLab Community Edition ed Enterprise Edition. Il problema interessa il motore Onigmo, integrato nell’ambiente Ruby distribuito con GitLab, e può consentire a un attaccante remoto non autenticato di eseguire codice arbitrario sul server in determinate condizioni. La critical patch release pubblicata da GitLab il 21 ottobre assegna alla vulnerabilità CVSS 10,0 e indica come potenzialmente interessate tutte le versioni dalla 7.0, rilasciata nel 2014, fino alle rispettive release corrette. La portata temporale rappresenta l’elemento distintivo rispetto alla precedente vulnerabilità GitLab CVE-2026-97229, corretta il 12 ottobre, che colpiva soltanto le versioni dalla 19.2. Il nuovo aggiornamento richiede quindi un ulteriore intervento anche agli amministratori che avevano installato le patch precedenti. Le versioni corrette sono 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1, distribuite eccezionalmente anche su quattro rami precedenti a quelli normalmente supportati. GitLab.com è già aggiornato e gli ambienti GitLab Dedicated sulle release interne indicate dal produttore non richiedono ulteriori interventi. Il ricercatore joaxcar ha segnalato la vulnerabilità attraverso HackerOne, ma GitLab non ha pubblicato dettagli sufficienti a definire tutti i prerequisiti necessari per sfruttarla. Sono disponibili due regole di rilevamento, Onigmo native worker crash e Org mode render error burst, destinate all’analisi dei log delle istanze self-managed. Non risultano prove pubbliche di sfruttamento della nuova CVE, a differenza delle precedenti vulnerabilità GitLab entrate nel catalogo KEV di CISA, per le quali l’exploitation era già stata documentata.

Leggi anche: GitLab CVSS 10, attacchi su Artifactory, PaperCut e Cisco FMC

Node.js espone la memoria del decoder Brotli a possibili attacchi RCE

Il secondo problema interessa CVE-2026-111497, vulnerabilità classificata High dal progetto Node.js e identificata nel codice di decompressione Brotli integrato nel runtime. Il difetto consiste in una scrittura fuori dai limiti del buffer, condizione che può provocare corruzione della memoria e, secondo l’advisory ufficiale, consentire l’esecuzione di codice remoto. L’impatto riguarda tutte e tre le linee supportate, Node.js 22.x, 24.x e 26.x, aggiornate il 21 ottobre rispettivamente alle versioni 22.23.4, 24.22.1 e 26.12.1. La comunicazione ufficiale del progetto Node.js attribuisce la segnalazione a OpenAI Codex Security, citando Khai Tran e Sylvie Mayer, e identifica nei maintainer Matteo Collina e Antoine du Hamel i responsabili della correzione. Il rischio interessa soprattutto le applicazioni che elaborano contenuti compressi provenienti da sorgenti non attendibili, ma la possibilità di sfruttamento concreto dipende dal percorso attraverso il quale il decoder viene raggiunto. L’advisory non documenta un exploit pubblico né campagne di attacco confermate e non specifica quali configurazioni applicative permettano di attivare la vulnerabilità. Il rilascio comprende inoltre altre nove CVE, tra cui problemi di validazione dei nomi host nei certificati TLS, gestione degli input DNS e controlli del Permission Model. La vicenda si distingue dai precedenti aggiornamenti di sicurezza Node.js e Fortinet perché interessa direttamente una libreria di compressione utilizzata dal runtime, anziché limitarsi ai meccanismi di autenticazione o alle API applicative. Le installazioni fuori supporto rappresentano un ulteriore problema, poiché non ricevono queste patch di sicurezza e richiedono una migrazione verso una release mantenuta.

HTTP/3 e QPACK trasformano pochi byte compressi in gigabyte di memoria

La ricerca pubblicata da Sébastien Féry di FoxIO amplia il problema alla disponibilità dei servizi HTTP/3. Il ricercatore ha individuato comportamenti vulnerabili in sette delle dieci implementazioni analizzate, dimostrando come il sistema di compressione QPACK possa essere sfruttato per generare richieste il cui costo in memoria supera di decine, centinaia o migliaia di volte la quantità di dati effettivamente trasmessa.

La ricerca originale Header Accordions di FoxIO spiega che le implementazioni vulnerabili controllano spesso le dimensioni degli header compressi senza applicare correttamente il limite all’insieme dei campi decompressi. Lo standard HTTP/3 impone invece di considerare la dimensione non compressa, aggiungendo 32 byte di overhead per ciascun campo, e di rispettare il budget complessivo durante l’elaborazione. In un test contro quic-go, un blocco di circa un megabyte ha generato oltre 160.000 header, occupando circa 15 MiB di memoria dopo la garbage collection; attraverso riferimenti ripetuti a una voce della tabella dinamica, FoxIO ha raggiunto rapporti di amplificazione prossimi a 4.000 volte negli ambienti Bun. Particolarmente grave è il caso del server HTTP/3 sperimentale di Bun, dove l’assenza di un controllo cumulativo consente di superare i 2 GB di header decompressi e provocare un overflow nel contatore della capacità del buffer. Il risultato può essere un ciclo infinito con CPU al 100%, riprodotto dai ricercatori attraverso uno stream di circa 516 KiB di traffico trasmesso. Non si tratta di esecuzione di codice o esfiltrazione, ma di una tecnica denial-of-service capace di compromettere la continuità operativa del servizio attraverso una singola connessione.

Le patch HTTP/3 non sono uniformi e alcune implementazioni restano esposte

La varietà delle librerie interessate rende la risposta operativa più articolata rispetto a GitLab e Node.js. FoxIO indica quic-go 0.57.0 come versione corretta per CVE-2025-64702, Cloudflare quiche 0.29.3 per CVE-2026-12523 e lsquic 4.9.0 per i difetti di amplificazione identificati nella propria implementazione. Anche Wireshark ha risolto CVE-2025-13945 nelle versioni 4.6.2 e 4.4.12, ma il suo problema riguarda il dissector HTTP/3 durante l’analisi di traffico decifrato o acquisizioni contenenti i relativi segreti, non un server HTTP/3 direttamente raggiungibile dalla rete. Alla data della ricerca, il 20 ottobre 2026, risultavano invece prive di correzione le implementazioni analizzate di Bun 1.4.3, h3 del progetto hyperium e aioquic/mitmproxy; questo stato non deve essere automaticamente esteso alle release successive senza controllare i rispettivi aggiornamenti. Per gli ambienti senza patch, FoxIO raccomanda di non esporre i server HTTP/3 sperimentali di Bun, di disabilitare HTTP/3 in mitmproxy con --set http3=false e di applicare un limite appropriato attraverso max_field_section_size nelle applicazioni basate su h3. IIS, Envoy e ngtcp2/nghttp3 non hanno mostrato il comportamento vulnerabile nei test descritti. La ricerca conferma quindi quanto già emerso con XRING, la vulnerabilità di XQUIC capace di interrompere server HTTP/3: la superficie d’attacco dei protocolli moderni dipende anche dalle scelte implementative e dalle librerie sottostanti, non soltanto dalle caratteristiche formali dello standard. Le correzioni già disponibili in alcuni progetti risalgono inoltre ai mesi precedenti, rendendo la disclosure di ottobre un consolidamento delle evidenze tecniche e non l’annuncio di sette nuove vulnerabilità scoperte simultaneamente.

Continua con:

OpenSSL 4.0.3 chiude una falla High in DTLS e nuovi DoS su QUIC

CISA e AWS: allarme per Zimbra, sandbox Node.js e servizi cloud

Tre vulnerabilità differenti richiedono una strategia comune di difesa

Per le imprese italiane che utilizzano repository GitLab self-managed, applicazioni Node.js e infrastrutture HTTP/3, il problema principale è identificare quali componenti vulnerabili siano effettivamente distribuiti e raggiungibili, senza limitarsi al nome del prodotto installato. Nel caso GitLab occorre verificare la release, installare la patch corretta e analizzare i log attraverso le regole pubblicate dal produttore, considerando anche le migrazioni del database che possono provocare downtime nelle installazioni single-node. Per Node.js, la priorità è aggiornare il runtime ed esaminare le applicazioni che affidano al decoder Brotli l’elaborazione di dati esterni. Sul fronte HTTP/3 diventa invece necessario individuare la libreria QUIC/QPACK effettivamente impiegata da reverse proxy, runtime e server applicativi, verificando che i limiti degli header vengano applicati alla dimensione decompressa e non soltanto ai byte ricevuti. La distinzione fra compromissione e indisponibilità del servizio resta fondamentale: GitLab e Node.js presentano vulnerabilità potenzialmente sfruttabili per eseguire codice, mentre i risultati di FoxIO documentano principalmente crash, memory exhaustion e blocchi della CPU. Non emergono dalle fonti esaminate campagne di sfruttamento confermate per queste specifiche nuove vulnerabilità, ma il rischio è concreto perché le debolezze si collocano in componenti condivisi da numerose applicazioni. Il punto comune non è un unico attacco, bensì l’errore di fidarsi dei limiti di un dato prima che venga interpretato, compilato o decompresso: quando quel controllo non corrisponde alle risorse effettivamente consumate, la protezione del servizio può fallire prima ancora che intervenga la logica applicativa.