Segui Apache ha rilasciato un aggiornamento di sicurezza urgente per affrontare CVE-2026-119618, una vulnerabilità critica di esecuzione di codice remoto nel modulo mod_http2 di Apache HTTP Server. Il difetto riguarda le versioni 2.4.55 fino a 2.4.70 di Apache HTTP Server e può consentire a un attaccante remoto non autenticato di corrompere la memoria dello heap e potenzialmente eseguire comandi arbitrari su server vulnerabili.
La vulnerabilità deriva da una sincronizzazione impropria quando Apache elabora richieste HTTP/2 simultanee. Più thread possono accedere a risorse condivise senza sufficiente coordinazione, creando una condizione di competizione che consente a un thread di modificare la memoria utilizzata da un altro. Lo sfruttamento riuscito può corrompere lo heap interno del server e infine portare all’esecuzione di codice remoto.
Solo le installazioni di Apache con HTTP/2 abilitato sono esposte al percorso di attacco noto. I server configurati esclusivamente per HTTP/1.1 non raggiungono la funzionalità vulnerabile di mod_http2. HTTP/2 può essere abilitato usando h2 per le connessioni TLS o h2c per HTTP/2 in chiaro tramite la direttiva Protocols di Apache.
Apache ha affrontato la vulnerabilità in HTTP Server 2.4.71, rilasciato l’11 novembre 2026. Anche le versioni standalone di mod_h2 da GitHub dalla 2.0.8 alla 2.0.42 sono interessate. L’avviso ufficiale di Apache attualmente non identifica una versione standalone corretta rilasciata separatamente.
Red Hat ha assegnato alla vulnerabilità un punteggio CVSS 3.1 di 9.8 per la sua valutazione generale, con sfruttamento a basso livello di complessità accessibile tramite la rete che non richiede né autenticazione né interazione dell’utente. Red Hat afferma ulteriormente che la ricerca ha dimostrato uno sfruttamento affidabile contro un server configurato di default con mod_http2 abilitato.
Tuttavia, a partire dal 12 novembre 2026, né Apache né i rapporti di sicurezza esaminati documentano uno sfruttamento in attacchi reali. Allo stesso modo, Wiz ha riportato nessuno sfruttamento conosciuto in circolazione al momento della pubblicazione. Le organizzazioni dovrebbero comunque dare priorità alla risoluzione perché la vulnerabilità è raggiungibile da remoto e la sua causa radice tecnica è ora pubblica.
Le organizzazioni possono rafforzare le difese contro lo sfruttamento emergente con la piattaforma AI-Native Detection Intelligence di SOC Prime, che consente ai team di sicurezza di operare con informazioni sulle minacce e accelerare l’ingegneria della rilevazione e la caccia alle minacce attraverso ambienti SIEM, EDR, XDR e Data Lake.
Rileva CVE-2026-119618 identificando i server Apache vulnerabili esposti a Internet con HTTP/2 abilitato e correlando l’attività sospetta di HTTP/2 con arresti anomali di Apache, processi figli anomali, esecuzione di comandi imprevisti, nuovi file creati e connessioni di rete in uscita insolite.
Il contenuto per il rilevamento potrebbe non essere disponibile per ogni CVE. Controlla la piattaforma SOC Prime per la copertura attuale. Se le rilevazioni rilevanti non sono ancora disponibili, controlla di nuovo poiché nuove informazioni sulle minacce e contenuti di rilevazione vengono continuamente aggiunti.
Analisi di CVE-2026-119618
CVE-2026-119618 riguarda le versioni di Apache HTTP Server dalla 2.4.55 alla 2.4.70 quando è presente la funzionalità vulnerabile di mod_http2 ed è abilitato HTTP/2. Il progetto standalone mod_h2 è interessato dalle versioni 2.0.8 alla 2.0.42. Apache classifica la questione come critica e la mappa a CWE-362, Esecuzione concorrente utilizzando risorse condivise con sincronizzazione impropria.
La vulnerabilità esiste nella funzione assign_headers() utilizzata dall’elaborazione HTTP/2 di Apache.
HTTP/2 differisce significativamente da HTTP/1.1 perché molti flussi possono operare contemporaneamente su una singola connessione. Il modulo mod_http2 di Apache utilizza quindi diversi thread per elaborare le richieste e gestire i flussi HTTP/2 simultaneamente.
Il problema si verifica quando questi thread interagiscono con la memoria condivisa senza sufficiente sincronizzazione. Secondo la valutazione tecnica di Red Hat, un lavoratore di flusso HTTP/2 può scrivere nella memoria posseduta dal thread di connessione attraverso un allocatore condiviso, senza blocchi.
Sotto un timing controllato dall’attaccante, l’accesso simultaneo può corrompere lo heap.
Le vulnerabilità di corruzione dello heap possono avere esiti diversi a seconda del layout della memoria e del controllo da parte dell’attaccante. Lo sfruttamento fallito può causare il crash dei processi di lavoro di Apache, mentre una corruzione sufficientemente controllata può modificare lo stato del programma o reindirizzare l’esecuzione.
Red Hat afferma che lo sfruttamento riuscito può consentire a un attaccante non autenticato di eseguire comandi arbitrari con i privilegi del processo di Apache HTTP Server. Questo può dare accesso agli attaccanti a dati dell’applicazione, file di configurazione, credenziali disponibili per il server web e altre risorse accessibili sotto quel contesto di sicurezza.
La vulnerabilità è particolarmente preoccupante sui sistemi esposti a Internet perché non è richiesta alcuna autenticazione valida, né account, password, chiave API o altri requisiti. Un attaccante ha solo bisogno di accesso alla rete per un endpoint HTTP/2 colpito.
L’esposizione dipende comunque dalla configurazione.
Apache HTTP Server deve effettivamente offrire HTTP/2. Gli amministratori possono abilitarlo tramite la direttiva Protocols usando:
Protocols h2 http/1.1
per HTTP/2 su TLS, oppure:
Protocols h2c http/1.1
dove è supportato HTTP/2 in chiaro.
La direttiva può essere configurata globalmente o su singoli virtual hosts, il che significa che gli amministratori dovrebbero ispezionare sia le configurazioni a livello di server che quelle per sito quando valutano l’esposizione.
Un server che esegue una versione di Apache affetta ma serve solo HTTP/1.1 non è vulnerabile attraverso questo difetto. Red Hat conferma specificamente che sistemi senza HTTP/2 abilitato non raggiungono il percorso di codice colpito.
L’intervallo colpito upstream di Apache non dovrebbe essere applicato ciecamente ai pacchetti delle distribuzioni Linux.
Le versioni precedenti di Red Hat Enterprise Linux 8 e versioni precedenti non contengono il codice vulnerabile e non sono colpite. RHEL 9 e RHEL 10 includono pacchetti mod_http2 colpiti, ma Red Hat valuta il problema come Importante piuttosto che Critico su quelle piattaforme.
La differenza deriva dai dettagli di implementazione. Su RHEL 9 e 10, ogni flusso HTTP/2 riceve un allocatore di memoria separato anziché condividere lo stesso allocatore con la connessione. Red Hat afferma che questa architettura aumenta notevolmente la complessità dello sfruttamento, sebbene i sistemi colpiti richiedano ancora aggiornamenti di sicurezza.
Red Hat ha rilasciato pacchetti corretti per diversi flussi di RHEL 9 e RHEL 10 l’11 novembre. Gli amministratori che utilizzano pacchetti Linux mantenuti dal fornitore dovrebbero applicare l’aggiornamento di sicurezza della loro distribuzione anziché determinare la vulnerabilità unicamente dalla versione di Apache upstream visualizzata dal server.
Apache HTTP Server 2.4.71 fornisce la correzione upstream. La correzione modifica il comportamento vulnerabile di sincronizzazione e gestione della memoria in modo che le operazioni HTTP/2 concomitanti non possano interagire con le risorse condivise colpite in maniera non sicura.
La vulnerabilità è stata scoperta indipendentemente tramite due sforzi di ricerca.
L’OSS Scanner di Anthropic ha segnalato il problema al team di sicurezza di Apache il 26 ottobre 2026 con l’identificativo ANT-2026-MAPKT6MZ. Anthony Weems e Simon Scannell della Google Cloud Vulnerability Research hanno segnalato indipendentemente la vulnerabilità il 3 novembre. Apache ha rilasciato la correzione l’11 novembre.
Il record CVE è stato pubblicato l’11 novembre 2026.
La situazione PoC di CVE-2026-119618 richiede un’interpretazione attenta. Red Hat afferma che la ricerca pubblica ha dimostrato un exploit affidabile contro un server configurato di default con mod_http2 abilitato. Tuttavia, The Hacker News e Wiz hanno riportato che nessun exploit RCE disponibile pubblicamente era stato identificato quando i loro rapporti sono stati pubblicati. I progetti pubblici su GitHub che affermano di avere scanner o strumenti correlati allo sfruttamento non devono quindi essere interpretati automaticamente come codice RCE armato convalidato.
Questa distinzione è operativamente significativa. I difensori dovrebbero presumere che il difetto sia tecnicamente sfruttabile mentre evitano affermazioni che un exploit armato e affidabile stia già circolando ampiamente a meno che non emergano ulteriori prove.
Per la rilevazione di CVE-2026-119618, i team di sicurezza dovrebbero innanzitutto identificare i sistemi esposti piuttosto che affidarsi solo alle firme degli exploit.
Gli amministratori possono confermare se il modulo HTTP/2 è caricato utilizzando:
apachectl -M | grep http2
Dovrebbero quindi ispezionare i file di configurazione di Apache per direttive Protocols contenenti h2 o h2c, comprese le direttive definite all’interno di singoli virtual hosts.
La scoperta di servizi esterni può anche identificare server che negoziano HTTP/2 tramite TLS ALPN. Tuttavia, l’identificazione della versione da sola può essere fuorviante perché le distribuzioni Linux spesso retroportano le correzioni delle vulnerabilità senza modificare la stringa di versione che appare come upstream.
La telemetria di runtime dovrebbe essere correlata con il traffico HTTP/2 sospetto. I potenziali indicatori comportamentali includono crash ripetuti dei worker di Apache, fault di segmentazione, riavvii anomali, messaggi di corruzione della memoria o improvvisa instabilità del servizio associata a raffiche richieste HTTP/2 insolite.
Poiché lo sfruttamento riuscito può fornire esecuzione di comandi, anche la telemetria dell’endpoint e dell’host dovrebbe essere esaminata per processi figli insoliti generati da Apache.
Esempi includono httpd o apache2 che lanciano inaspettatamente shell, interpreti di scripting, utility di download o comandi di amministrazione di sistema.
I team di sicurezza dovrebbero indagare sulle relazioni tra processi come:
httpd → /bin/sh
apache2 → bash
httpd → curl
apache2 → wget
o altre catene di esecuzione incoerenti con il comportamento normale dell’applicazione ospitata.
La creazione di file all’interno di directory temporanee, root web, percorsi di avvio, o cartelle applicative scrivibili può anche indicare attività di post-sfruttamento. Anche le connessioni in uscita impreviste dai processi worker di Apache dovrebbero essere sottoposte a una simile analisi.
Attualmente non ci sono IOC specifici per campagne pubblicati dal fornitore per CVE-2026-119618, come indirizzi IP dannosi, domini, hash di payload o infrastrutture di attacco, perché Apache e le fonti esaminate non hanno riportato sfruttamenti in the wild. Ciò rende la valutazione della configurazione e il monitoraggio basato sul comportamento più preziosi rispetto alla corrispondenza di indicatori statici.
Mitigazione di CVE-2026-119618
La principale soluzione è aggiornare le installazioni colpite di Apache HTTP Server alla versione 2.4.71 o applicare il pacchetto di sicurezza corretto fornito dal fornitore del sistema operativo. Apache 2.4.71 è stato rilasciato l’11 novembre 2026 e contiene la correzione upstream.
Le organizzazioni dovrebbero dare priorità alle distribuzioni Apache esposte a Internet con HTTP/2 abilitato perché questi sistemi espongono direttamente la funzionalità vulnerabile a traffico di rete non attendibile.
Gli amministratori dovrebbero seguire i seguenti passaggi:
- Inventaria le distribuzioni di Apache HTTP Server tra ambienti di produzione, sviluppo, cloud e container.
- Identifica le installazioni che eseguono Apache dalla versione 2.4.55 alla 2.4.70.
- Verifica se mod_http2 è caricato.
- Ispeziona le direttive Protocols globali e dei virtual hosts per h2 o h2c.
- Aggiorna le distribuzioni upstream di Apache alla versione 2.4.71 o successiva.
- Applica pacchetti specifici alla distribuzione quando Apache è gestito tramite Debian, Red Hat, Amazon Linux o un altro fornitore di sistemi operativi.
- Riavvia Apache dopo la patch per garantire che i processi worker vulnerabili non siano più in esecuzione.
- Verifica la configurazione effettiva del server HTTP dopo la risoluzione.
- Esamina la telemetria storica per attività sospette su sistemi esposti a Internet che sono stati vulnerabili prima della patch.
Gli amministratori non dovrebbero presumere che l’installazione di un pacchetto di sistema operativo con un numero di versione inferiore alla 2.4.71 significhi che il sistema rimanga vulnerabile. Fornitori come Red Hat retroportano le correzioni di sicurezza nelle loro versioni di pacchetto, quindi l’avviso di distribuzione rilevante dovrebbe essere considerato autorevole.
L’avviso ufficiale di Apache non fornisce una soluzione alternativa. Tuttavia, le organizzazioni che non possono patchare immediatamente possono temporaneamente rimuovere HTTP/2 dalle configurazioni esposte, eliminando l’accesso al percorso di codice vulnerabile noto. Wiz raccomanda di limitare il server a HTTP/1.1 fino a quando l’aggiornamento non può essere implementato.
Ad esempio:
Protocols http/1.1
Le organizzazioni che applicano questa soluzione alternativa dovrebbero ispezionare tutti i virtual hosts poiché una configurazione specifica del sito può abilitare h2 o h2c in modo indipendente.
La rimozione di HTTP/2 può influire sulle prestazioni delle applicazioni e sul comportamento dei client, quindi il cambiamento dovrebbe essere testato e trattato come una misura temporanea di riduzione del rischio piuttosto che come un sostituto per l’installazione dell’aggiornamento di sicurezza.
La strategia di mitigazione CVE-2026-119618 dovrebbe includere anche la riduzione dell’esposizione non necessaria. I servizi amministrativi o interni di Apache che non necessitano di connettività diretta a Internet dovrebbero essere limitati attraverso segmentazione di rete, bilanciatori di carico, proxy inversi, politiche firewall o indirizzamento privato.
Le organizzazioni che utilizzano rilasci standalone di mod_h2 tra la 2.0.8 e la 2.0.42 richiedono particolare attenzione. Apache identifica questi rilasci come colpiti, mentre The Hacker News ha riportato che nessun rilascio standalone corretto era stato pubblicato al momento del suo rapporto del 12 novembre. Disabilitare HTTP/2 o migrare a un pacchetto Apache HTTP Server contenente la correzione upstream può quindi essere necessario finché un aggiornamento standalone appropriato non sarà disponibile.
Se viene scoperta attività sospetta, i difensori dovrebbero isolare il server colpito dove operativamente fattibile e preservare i log di accesso di Apache, i log degli errori, i log di sistema, la telemetria dei processi, le connessioni di rete e le informazioni rilevanti sulla memoria o sugli arresti.
Lo sfruttamento riuscito dovrebbe essere trattato come potenziale compromissione del server piuttosto che semplicemente uno crash del servizio. Gli investigatori dovrebbero cercare nuovi file, webshell, codice applicativo alterato, meccanismi di persistenza, credenziali rubate, traffico in uscita sospetto e prove di movimento laterale.
Le credenziali accessibili al processo di Apache, inclusi password di database, chiavi API, credenziali cloud, chiavi private TLS o segreti memorizzati nella configurazione dell’applicazione, dovrebbero essere esaminate e ruotate quando le prove suggeriscono che si è verificata un’esecuzione di codice controllata dall’attaccante.
FAQ
Cosa è CVE-2026-119618 e come funziona?
CVE-2026-119618 è una condizione di competizione critica nel modulo mod_http2 di Apache HTTP Server. L’elaborazione HTTP/2 concomitante può causare l’accesso di più thread alla memoria condivisa senza corretta sincronizzazione, risultando in una corruzione dello heap. Un attaccante remoto non autenticato che può raggiungere un servizio HTTP/2 colpito potrebbe riuscire a manipolare questa corruzione ed eseguire codice arbitrario con i privilegi del processo server Apache.
Quando è stato scoperto per la prima volta CVE-2026-119618?
L’OSS Scanner di Anthropic ha segnalato il difetto ad Apache il 26 ottobre 2026. Anthony Weems e Simon Scannell della Google Cloud Vulnerability Research lo hanno segnalato indipendentemente il 3 novembre. Apache ha divulgato pubblicamente la vulnerabilità e rilasciato Apache HTTP Server 2.4.71 contenente la correzione l’11 novembre 2026.
Qual è l’impatto di CVE-2026-119618 sui sistemi?
Lo sfruttamento riuscito può corrompere lo heap di Apache e portare all’esecuzione di codice remoto non autenticata. Un attaccante può eseguire comandi utilizzando i privilegi del processo Apache, potenzialmente accedere a dati sensibili dell’applicazione, modificare file, stabilire persistenza, interrompere servizi o utilizzare il server compromesso come punto di ingresso per ulteriori attacchi. Red Hat assegna al difetto un punteggio CVSS 3.1 generico di 9.8.
CVE-2026-119618 può ancora colpirmi nel 2026?
Sì. Le versioni di Apache HTTP Server dalla 2.4.55 alla 2.4.70 rimangono vulnerabili quando mod_http2 e HTTP/2 sono abilitati a meno che il fornitore del sistema operativo non abbia retroportato la correzione. A partire dal 12 novembre 2026, le fonti esaminate non riportano sfruttamenti confermati in the wild, ma uno sfruttamento affidabile è stato dimostrato nella ricerca di sicurezza.
Come posso proteggermi da CVE-2026-119618?
Aggiorna Apache HTTP Server alla versione 2.4.71 o successiva, o installa il pacchetto corretto fornito dalla tua distribuzione Linux. Se non è possibile patchare immediatamente, disabilita temporaneamente HTTP/2 rimuovendo h2 e h2c dalla configurazione Protocols e limita l’accesso esterno non necessario. I team di sicurezza dovrebbero monitorare l’avviso di Apache e i tracker di sicurezza della distribuzione per dettagli aggiornati su CVE-2026-119618 mentre ulteriori ricerche sugli exploit e informazioni sulla risoluzione diventano disponibili.
