FortiSIEM espone una RCE con exploit pubblico, Cisco indaga PHP2Shell

🛡️ Executive Summary

• Fortinet FortiSIEM espone una RCE CVSS 9,4 con exploit pubblico: Horizon3.ai dimostra come sfruttare il servizio gRPC per sovrascrivere file ed eseguire comandi senza autenticazione.
• Cisco indaga sull’impatto delle due vulnerabilità PHP2Shell su ISE, Catalyst Center, SD-WAN Manager e altri prodotti. Amazon ha intanto rilevato tentativi di sfruttamento PHP già dal 17 ottobre.
• Node.js corregge una possibile RCE nel decoder Brotli, mentre la ricerca FoxIO documenta attacchi QPACK capaci di provocare esaurimento della memoria e blocchi nei server HTTP/3.

Fortinet, Cisco, Node.js e diverse implementazioni HTTP/3 affrontano vulnerabilità che interessano direttamente la sicurezza delle infrastrutture enterprise. Il caso più urgente per la disponibilità di strumenti offensivi riguarda FortiSIEM, dove Horizon3.ai ha pubblicato un exploit funzionante per una vulnerabilità di esecuzione remota di codice senza autenticazione. Cisco ha invece avviato una valutazione dei propri prodotti dopo la divulgazione delle due RCE PHP2Shell, già oggetto di tentativi di sfruttamento documentati da Amazon Threat Intelligence. A completare il quadro ci sono un errore di memoria nel decoder Brotli di Node.js e diverse vulnerabilità di amplificazione QPACK in HTTP/3. Le quattro vicende richiedono interventi differenti: patch immediata dove esiste un exploit pubblico, verifica delle dipendenze nei prodotti Cisco e aggiornamenti mirati per runtime applicativi e server web.

FortiSIEM, exploit pubblico sfrutta una falla gRPC senza autenticazione

La vulnerabilità più delicata è CVE-2026-106173, un problema di path traversal classificato CVSS 9,4 nel servizio gRPC di Fortinet FortiSIEM. Il produttore ha pubblicato il bollettino FG-IR-26-180 il 13 ottobre, ma il rischio operativo è cresciuto il 20 ottobre quando Horizon3.ai ha distribuito un proof-of-concept pubblico accompagnato da una ricostruzione completa del percorso verso l’esecuzione remota di codice. La falla interessa il servizio phQueryMaster, raggiungibile attraverso la porta TCP 27918, e permette a un attaccante remoto non autenticato di manipolare i metadati utilizzati per costruire il percorso di scrittura dei risultati delle interrogazioni. Nella ricerca originale di Horizon3.ai viene dimostrato che una combinazione di attraversamento delle directory e caratteri nulli può aggirare le restrizioni previste dal servizio, trasformando una normale operazione di scrittura in una primitiva per sovrascrivere file esterni alla directory autorizzata. Il successivo passaggio all’esecuzione di codice sfrutta un componente locale che esegue periodicamente uno script di controllo del servizio Redis. Non è necessario conoscere credenziali amministrative quando la porta vulnerabile è raggiungibile, ma la possibilità di attacco dipende dall’esposizione del servizio gRPC e dalla versione installata.

La ricerca individua anche una debolezza nella capacità di rilevare lo sfruttamento: Horizon3.ai non ha identificato log applicativi che registrino esplicitamente l’abuso della vulnerabilità. Gli amministratori devono quindi esaminare modifiche inattese ai file di sistema e ai componenti eseguiti periodicamente, soprattutto quando i relativi timestamp non risultano coerenti con le normali attività di manutenzione. Il precedente delle vulnerabilità FortiSIEM con exploit pubblici e attacchi denial-of-service mostra come i sistemi incaricati di raccogliere e correlare eventi di sicurezza possano diventare essi stessi bersagli privilegiati. La pubblicazione di un exploit funzionante non equivale alla conferma di campagne di compromissione già avvenute, ma riduce sensibilmente le competenze necessarie a tentare lo sfruttamento.

Leggi anche: Fortinet e Node.js patchano vulnerabilità critiche con impatto enterprise

Fortinet corregge FortiSIEM 7.5.0 e raccomanda di limitare la porta 27918

FortiSIEM 7.5.0 è vulnerabile e deve essere aggiornato almeno alla versione 7.5.1, mentre il ramo 7.6 viene indicato come non interessato. Il record CVE mantenuto da Fortinet include nel perimetro vulnerabile anche diversi rami precedenti, dalla serie 7.0 alla 7.4, rendendo necessario consultare la matrice correttiva del produttore anziché considerare protette tutte le installazioni che non utilizzano la 7.5.0. Gli ambienti legacy devono essere verificati separatamente, perché non è sufficiente applicare il numero di versione suggerito per un ramo differente. Come misura temporanea, Fortinet indica la possibilità di restringere l’accesso alla porta TCP 27918, evitando che il servizio gRPC venga raggiunto da reti non autorizzate. La limitazione non corregge l’errore di validazione dei percorsi, ma riduce la superficie raggiungibile dall’attaccante in attesa dell’aggiornamento.

La priorità dipende anche dal ruolo ricoperto da FortiSIEM nell’infrastruttura: un sistema SIEM può mantenere connessioni verso dispositivi di rete, server e sorgenti di log, oltre a informazioni necessarie al loro monitoraggio. Compromettere la piattaforma di osservazione può quindi compromettere anche l’affidabilità delle informazioni utilizzate per individuare gli incidenti. Per questo gli amministratori devono affiancare alla patch il controllo dei file modificati, degli accessi alla porta gRPC e dell’integrità dei componenti locali, evitando di considerare conclusa l’analisi soltanto perché il software è stato aggiornato.

Cisco avvia l’indagine su PHP2Shell in ISE, Catalyst Center e SD-WAN

Cisco ha pubblicato il 21 ottobre 2026 un advisory critico dedicato a CVE-2026-109618 e CVE-2026-109619, le due vulnerabilità conosciute come PHP2Shell. La prima riguarda la gestione degli errori di esaurimento della memoria nel runtime PHP, mentre la seconda interessa riferimenti a strutture interne che possono sopravvivere alla conclusione di una richiesta e venire utilizzati quando la memoria è già stata liberata. Entrambe consentono, in condizioni documentate dal progetto PHP, esecuzione remota di codice senza autenticazione e sono classificate CVSS 4.0 di 9,2. Nel Security Advisory Cisco cisco-sa-php-october26-Jj384Daq il produttore elenca fra i sistemi sotto verifica Cisco Identity Services Engine, Hypershield, Catalyst Center, Catalyst SD-WAN Manager, Nexus Dashboard Insights, Cisco Expressway, numerose piattaforme destinate agli operatori di telecomunicazioni e diversi servizi cloud.

La presenza di un prodotto nell’elenco sotto indagine non dimostra che quel prodotto sia vulnerabile. Nella versione dettagliata dell’advisory verificata, Cisco non aveva ancora attribuito le due CVE a prodotti specifici nella sezione Vulnerable Products e dichiarava l’assenza di workaround generali. Aveva inoltre confermato come non vulnerabili Cisco AI Defense nella distribuzione ibrida on-premises, Cisco Umbrella e Cisco Cloud Hosted Services. Le valutazioni devono comunque essere aggiornate attraverso le successive revisioni del bollettino, perché l’elenco dei prodotti analizzati può cambiare. Il punto più importante è che non tutte le appliance Cisco utilizzano necessariamente PHP nello stesso modo, né espongono un percorso di esecuzione accessibile a richieste HTTP non autenticate. Le quattro versioni PHP corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35, come già documentato nell’approfondimento sulle patch PHP2Shell per le due RCE senza autenticazione. Per le appliance che incorporano l’interprete, tuttavia, non è necessariamente corretto sostituire manualmente il runtime: gli amministratori devono attendere le indicazioni Cisco e utilizzare firmware o aggiornamenti certificati per il prodotto.

PHP2Shell è già oggetto di tentativi di attacco precedenti alle patch

La distinzione tra vulnerabilità teorica e attività offensiva è cambiata dopo la pubblicazione della ricerca di Amazon Threat Intelligence. Analizzando la telemetria della rete di honeypot MadPot, Amazon ha individuato un tentativo di sfruttamento di PHP2Shell risalente al 17 ottobre 2026, quattro giorni prima della divulgazione pubblica delle vulnerabilità. Ulteriori tentativi sono stati registrati il 21 ottobre, alcune ore prima della disponibilità delle patch, seguiti da un aumento dell’attività dopo il rilascio. Amazon ha identificato diverse infrastrutture di origine e ha precisato che non è possibile stabilire automaticamente se i tentativi osservati avrebbero avuto successo contro server di produzione. La segnalazione conferma l’esistenza di attività offensive contro PHP2Shell, non la compromissione di specifici apparati Cisco. Questo elemento modifica le priorità degli amministratori di applicazioni PHP raggiungibili da Internet: la ricerca retrospettiva deve partire almeno dal 17 ottobre, mentre l’aggiornamento del runtime resta l’unica correzione completa. La distinzione è rilevante anche rispetto al precedente allarme PHP2Shell sulle versioni vulnerabili e sugli hosting condivisi, pubblicato quando non erano ancora disponibili tutte le informazioni tecniche e le versioni corrette.

Node.js corregge la RCE Brotli nelle tre linee supportate

Il terzo aggiornamento riguarda CVE-2026-111497, vulnerabilità classificata High nel decoder Brotli integrato in Node.js. Il problema consiste in una scrittura fuori dai limiti della memoria che può consentire esecuzione remota di codice quando il runtime elabora dati compressi non attendibili attraverso il percorso vulnerabile. Il bollettino ufficiale Node.js del 21 ottobre conferma il coinvolgimento delle linee 22.x, 24.x e 26.x, corrette rispettivamente con le versioni 22.23.4, 24.22.1 e 26.12.1. La vulnerabilità è stata segnalata da OpenAI Codex Security, con Khai Tran e Sylvie Mayer, e corretta dai manutentori Matteo Collina e Antoine du Hamel. Il rilascio comprende altre nove CVE, fra cui problemi di validazione dei certificati TLS, input DNS e controlli del Permission Model. Per le applicazioni enterprise la priorità consiste nell’identificare i servizi che utilizzano effettivamente il decoder e verificare le immagini container, i processi Node.js e gli ambienti che incorporano copie del runtime non aggiornate. Non emerge dall’advisory ufficiale una conferma di sfruttamento attivo della specifica CVE, ma l’assenza di exploit osservati non elimina il rischio derivante dalla corruzione della memoria.

HTTP/3 e QPACK espongono sette implementazioni a denial-of-service

La quarta vicenda è il risultato della ricerca Header Accordions pubblicata da Sébastien Féry di FoxIO il 20 ottobre. La ricerca originale sulle vulnerabilità QPACK documenta problemi in sette delle dieci implementazioni HTTP/3 analizzate. Un client remoto non autenticato può inviare blocchi di header compressi relativamente piccoli e indurre il server ad allocare quantità di memoria enormemente superiori, provocando esaurimento delle risorse, crash o blocchi della CPU. Il comportamento nasce dalla mancata applicazione di un limite cumulativo agli header decompressi, talvolta aggravata dall’omissione dei 32 byte di overhead per campo previsti dalle specifiche HTTP/3. Nei test contro Bun, FoxIO ha osservato un’amplificazione vicina a 4.000 volte, mentre una particolare condizione nel codice di gestione dei buffer può mandare il processo in un ciclo infinito. Le correzioni disponibili comprendono quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0 e Wireshark 4.6.2/4.4.12. Alla data della ricerca rimanevano senza patch le implementazioni esaminate di Bun 1.4.3, h3 di hyperium e aioquic/mitmproxy. FoxIO suggerisce di non esporre i server HTTP/3 sperimentali di Bun non corretti, disabilitare temporaneamente HTTP/3 in mitmproxy e applicare limiti appropriati a max_field_section_size nelle applicazioni basate su h3. L’impatto documentato riguarda principalmente denial-of-service e consumo incontrollato di risorse, non esecuzione remota di codice.

Continua con:

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

Exploit pubblico, sfruttamento confermato e patch definiscono le priorità

Le quattro vicende dimostrano perché la gravità CVSS non possa essere utilizzata come unico criterio per stabilire l’urgenza degli interventi. FortiSIEM richiede attenzione immediata perché un exploit pubblico permette di tentare l’esecuzione di codice senza autenticazione contro i servizi raggiungibili. PHP2Shell richiede aggiornamenti urgenti perché Amazon ha documentato tentativi di sfruttamento precedenti alla divulgazione, anche se Cisco sta ancora verificando l’esposizione delle proprie piattaforme. Node.js dispone di patch per una vulnerabilità potenzialmente sfruttabile come RCE, mentre QPACK interessa soprattutto la disponibilità di servizi HTTP/3 costruiti su implementazioni vulnerabili. Per aziende e pubbliche amministrazioni, la risposta deve comprendere inventario dei componenti, verifica delle versioni effettivamente distribuite, controllo delle interfacce esposte e analisi retrospettiva degli eventi, senza confondere la pubblicazione di un proof-of-concept con la conferma di una compromissione. Il punto comune è la gestione di input non attendibili all’interno di componenti privilegiati: quando la validazione viene eseguita troppo tardi o su dati non ancora completamente interpretati, una funzione ordinaria di elaborazione può diventare un percorso verso la compromissione del sistema o l’interruzione del servizio.