Gli amministratori PHP stanno affrontando un aggiornamento di sicurezza urgente dopo che i manutentori hanno annunciato un rilascio straordinario per affrontare due vulnerabilità critiche. I difetti, tracciati dai ricercatori di sicurezza come CVE-2026-109618 e CVE-2026-109619, hanno ricevuto un punteggio CVSS v4.0 di 9.2 dal team di sicurezza di PHP. I ricercatori di watchTowr descrivono entrambi i problemi come vulnerabilità di esecuzione di codice remoto.
Il rilascio d’emergenza è previsto per il 21 ottobre 2026 alle 14:00 UTC. PHP ha anticipato la divulgazione dopo che le informazioni sulle vulnerabilità sono state presumibilmente trapelate prima della data di rilascio coordinata. Al momento della scrittura, PHP non ha divulgato i componenti vulnerabili, i requisiti di sfruttamento, le versioni interessate o le cause radici tecniche e afferma che questi dettagli accompagneranno gli aggiornamenti di sicurezza.
I ricercatori hanno soprannominato informalmente il paio di vulnerabilità “PHP2Shell”, anche se questo nome non proviene dal Progetto PHP. La fuga iniziale sosteneva che i difetti potessero influenzare le versioni PHP risalenti a PHP 5 e gli ha assegnato punteggi CVSS di 10.0. Tuttavia, la valutazione ufficiale di PHP è 9.2, e la gamma di versioni dichiarata non è stata ancora confermata da un avviso ufficiale del fornitore.
L’impatto potenziale è comunque significativo. PHP alimenta un gran numero di siti web, applicazioni web, sistemi di gestione dei contenuti, piattaforme di e-commerce, API, pannelli di hosting e servizi aziendali personalizzati. Se l’esecuzione di codice remoto è confermata nelle configurazioni comunemente distribuite, uno sfruttamento di successo potrebbe dare agli attaccanti un percorso diretto da un’applicazione web esposta al compromesso a livello di server.
I team di sicurezza alla ricerca di opportunità di rilevamento CVE-2026-109618 dovrebbero prioritizzare il monitoraggio basato sul comportamento mentre le firme specifiche dello sfruttamento rimangono non disponibili. Le attività sospette includono processi PHP o del server web che lanciano inaspettatamente shell, interpreti, utilità da riga di comando o strumenti di download.
I clienti SOC Prime possono sfruttare la Piattaforma AI-Native Detection Intelligence per accedere a contenuti di rilevamento aggiornati continuamente per lo sfruttamento della vulnerabilità e il comportamento post-compromissione associato. Le regole di rilevamento possono essere applicate su più ambienti SIEM, EDR e Data Lake e allineate con il framework MITRE ATT&CK®.
Clicca Esplora gli Stratagemi di Rilevamento per accedere ai contenuti SOC rilevanti per le vulnerabilità emergenti. Per rilevare CVE-2026-109619 e i tentativi di sfruttamento associati, i difensori dovrebbero combinare analisi comportamentali con telemetria del server web, dell’endpoint e di rete man mano che l’intelligenza tecnica diventa disponibile.
I team di sicurezza possono anche utilizzare Prime Architect per trasformare l’intelligenza sulle vulnerabilità emergenti in regole Sigma e query di caccia personalizzate, convalidare la logica di rilevamento, visualizzare i potenziali Attack Flow e tradurre rapidamente i contenuti di rilevamento sui platform di sicurezza supportati.
Analisi di CVE-2026-109618 e CVE-2026-109619
Il 20 ottobre 2026, il team di sicurezza PHP ha emesso un avviso anticipato che due vulnerabilità critiche sarebbero state affrontate attraverso un rilascio di sicurezza eccezionale il giorno successivo. Entrambi hanno ricevuto una valutazione CVSS v4.0 di 9.2, e gli amministratori sono stati invitati a prepararsi per aggiornamenti immediati. PHP ha anche riservato l’opzione di rilasciare correzioni prima se le informazioni tecniche diventano pubbliche o se viene rilevato uno sfruttamento attivo.
L’annuncio è seguito alla fuga di informazioni riguardante due vulnerabilità soggette a embargo. Il materiale trapelato ha identificato CVE-2026-109618 e CVE-2026-109619 e ha caratterizzato entrambi come difetti di esecuzione di codice remoto. watchTowr ha successivamente confermato a BleepingComputer che le vulnerabilità sono reali e ha affermato che i suoi ricercatori credono di aver riprodotto con successo una di esse.
Tuttavia, ci sono importanti differenze tra le informazioni trapelate e quanto confermato ufficialmente da PHP.
PHP ha assegnato a entrambe le vulnerabilità un punteggio CVSS v4.0 di 9.2 anziché il punteggio CVSS 10.0 circolato nella fuga di notizie. PHP non ha inoltre confermato quali branche sono vulnerabili, se lo sfruttamento richiede un particolare modello di distribuzione PHP o configurazione, o se è necessaria l’autenticazione.
L’affermazione che CVE-2026-109618 interessa le versioni PHP 5, 6, 7 e 8 proviene da ricercatori e da informazioni trapelate piuttosto che dall’avviso ufficiale di PHP. watchTowr stesso nota che questo ambito non è ancora stato confermato dal fornitore.
Un’analisi accurata di CVE-2026-109618 deve quindi separare i fatti confermati dalla ricerca preliminare. Ciò che è attualmente confermato è che PHP considera due vulnerabilità critiche, valuta entrambe a 9.2 e ritiene che il rischio giustifichi un rilascio di sicurezza straordinario fuori ciclo. I ricercatori caratterizzano i difetti come vulnerabilità RCE, ma i loro meccanismi di base restano soggetti a embargo.
Questa distinzione è rilevante anche quando si valutano ambienti PHP legacy. Attualmente, il progetto PHP fornisce aggiornamenti di sicurezza solo per le branche supportate da 8.2 a 8.5. PHP 8.2 e 8.3 ricevono patch di sicurezza, mentre 8.4 e 8.5 rimangono sotto supporto attivo. Le branche più vecchie, comprese PHP 8.1, 8.0, PHP 7.x e PHP 5.x, sono giunte a fine vita e non riceveranno patch upstream se alla fine si dimostrano vulnerabili.
Ciò potrebbe creare uno scenario di mitigazione particolarmente impegnativo per le organizzazioni che operano applicazioni vecchie che non possono essere facilmente migrate. I sistemi PHP legacy esposti su Internet rappresenterebbero una preoccupazione significativa se l’ampia esposizione alla versione riportata venisse confermata.
Non è disponibile alcun PoC pubblico per CVE-2026-109618 al momento della scrittura. watchTowr afferma di credere di aver riprodotto con successo il problema ma sta intenzionalmente trattenendo le informazioni tecniche fino a quando non saranno disponibili le patch di sicurezza. Anche Huntress non aveva riprodotto le vulnerabilità ed era ignaro di codice di exploit disponibile pubblicamente.
Non è stata osservata alcuna sfruttamento attivo dai ricercatori citati in entrambi i report fino al 21 ottobre. Le vulnerabilità non erano inoltre elencate nel catalogo delle vulnerabilità conosciute di CISA al momento del report di The Hacker News.
Di conseguenza, non sono stati ancora pubblicati IOC per CVE-2026-109619. Attualmente non ci sono indirizzi IP, domini, hash di payload, schemi di richieste di exploit o altri indicatori di campagna direttamente associati allo sfruttamento di questa vulnerabilità.
Fino a quando i dettagli di exploit non saranno disponibili, i difensori dovrebbero invece monitorare segni generici di compromissione del server PHP. Comportamenti di alto valore includono php-fpm, php-cgi, httpd o apache2 che generano shell, motori di scripting, utilità di download o altri eseguibili inaspettati. Nuove web shell, modifiche inspiegabili nella radice web, cron job, operazioni pianificate, account appena creati e connessioni in uscita anomale dovrebbero anche innescare un’indagine.
I dettagli precisi per CVE-2026-109619 dovrebbero chiarire il componente PHP vulnerabile, i prerequisiti di attacco, le branche interessate, le dipendenze di configurazione e le versioni corrette una volta che PHP pubblicherà il rilascio di sicurezza.
Mitigazione per CVE-2026-109618 e CVE-2026-109619
Gli amministratori PHP dovrebbero innanzitutto costruire un inventario accurato di ogni distribuzione PHP nell’ambiente. Ciò include server web convenzionali Linux e Windows, nonché runtime PHP incorporati in apparecchi, applicazioni di terze parti, piattaforme di hosting e prodotti di amministrazione come cPanel o Plesk.
Per la mitigazione immediata di CVE-2026-109619, le organizzazioni dovrebbero prepararsi a distribuire l’aggiornamento di sicurezza d’emergenza di PHP appena le versioni patchate diventeranno disponibili. Le applicazioni esposte a Internet dovrebbero ricevere la massima priorità perché i sistemi raggiungibili da remoto presentano tipicamente la maggiore opportunità di sfruttamento.
Le organizzazioni che utilizzano pacchetti PHP forniti dalla distribuzione dovrebbero controllare il proprio fornitore Linux o provider di hosting per aggiornamenti di sicurezza backportati piuttosto che assumere che il solo numero di versione PHP upstream determini l’esposizione.
Le installazioni PHP legacy richiedono particolare attenzione. Se un’applicazione vulnerabile esegue una versione PHP giunta a fine vita per la quale non è disponibile alcuna patch ufficiale, le organizzazioni dovrebbero prioritizzare la migrazione a una branca supportata. Dove la migrazione immediata è impossibile, l’esposizione dovrebbe essere ridotta limitando l’accesso esterno, posizionando l’applicazione dietro controlli di rete appropriati o isolando temporaneamente il sistema.
Le linee guida CERT-EU citate da The Hacker News raccomandano di considerare l’isolamento delle applicazioni esposte a Internet dalle reti pubbliche quando una correzione non può essere immediatamente applicata.
I difensori dovrebbero inoltre rafforzare il monitoraggio attorno all’esecuzione di PHP. Avvisare quando i lavoratori PHP o i processi del server web generano utilità come shell, PowerShell, Bash, Python, Perl, curl, wget o altri programmi inaspettati per l’applicazione.
Se si sospetta uno sfruttamento, isolare il server interessato e conservare le prove prima della mitigazione. Gli artefatti rilevanti includono:
- Log di accesso e errore del server web
- Log dell’applicazione PHP e del runtime
- Telemetria dell’endpoint e dei processi
- File recentemente creati o modificati
- Contenuti della radice web
- Cron job e operazioni pianificate
- Account o chiavi SSH appena creati
- Connessioni di rete in uscita
- Attività di autenticazione e amministrativa
I team di sicurezza dovrebbero anche cercare in modo retrospettivo dopo il rilascio degli indicatori tecnici. Se gli schemi specifici di richiesta HTTP di exploit o le caratteristiche del payload diventano pubbliche, la telemetria storica del web e del proxy potrebbe identificare tentativi di compromissione che si sono verificati prima che le patch fossero applicate.
Le organizzazioni dovrebbero evitare di affidarsi esclusivamente a un WAF come sostituto permanente del patching. Fino a quando le cause radici tecniche non verranno divulgate, non esiste una regola WAF generica confermata che possa bloccare in modo affidabile entrambe le vulnerabilità senza conoscere i loro meccanismi di sfruttamento.
Sfruttando la Piattaforma AI-Native Detection Intelligence di SOC Prime, i team di sicurezza possono rafforzare continuamente la loro postura di rilevamento man mano che emergono nuove informazioni su queste vulnerabilità PHP.
Disclaimer: Il contenuto del rilevamento potrebbe non essere disponibile per ogni CVE. Controlla la Piattaforma SOC Prime per la copertura attuale. Se i rilevamenti pertinenti non sono ancora disponibili, ricontrolla Poiché nuove informazioni sulla minaccia e contenuti di rilevamento vengono continuamente aggiunti.
FAQ
Cosa sono CVE-2026-109618 e CVE-2026-109619 e come funzionano?
CVE-2026-109618 e CVE-2026-109619 sono due vulnerabilità critiche di PHP che i ricercatori di watchTowr descrivono come falle di esecuzione di codice remoto. PHP ha ufficialmente confermato due problemi critici con punteggi CVSS v4.0 di 9.2, ma non ha ancora rivelato le loro cause radici tecniche o i meccanismi di sfruttamento. Al momento della scrittura, non è quindi possibile descrivere in modo affidabile il flusso dell’attacco esatto. Si prevede che PHP pubblichi le informazioni tecniche con il suo rilascio di sicurezza d’emergenza.
Quando sono stati scoperti per la prima volta CVE-2026-109618 e CVE-2026-109619?
Le informazioni sulle vulnerabilità sono diventate pubbliche il 20 ottobre 2026, dopo che i dettagli di due vulnerabilità PHP soggette a embargo sono state presumibilmente trapelate prima della loro divulgazione pianificata. PHP ha emesso il suo avviso ufficiale in anticipo più tardi lo stesso giorno e ha programmato un rilascio di sicurezza d’emergenza per il 21 ottobre 2026 alle 14:00 UTC.
Qual è l’impatto di CVE-2026-109618 e CVE-2026-109619 sui sistemi?
I ricercatori di sicurezza caratterizzano entrambe le vulnerabilità come problemi di esecuzione di codice remoto. Se tale valutazione è confermata da PHP, uno sfruttamento di successo potrebbe potenzialmente consentire a un attaccante di eseguire codice su un server PHP vulnerabile e procedere con il dispiegamento di malware, il furto di credenziali, la persistenza, il movimento laterale o l’accesso ai dati a seconda dei privilegi del servizio interessato. PHP non ha ancora pubblicato le condizioni precise dello sfruttamento, quindi l’impatto esatto e i prerequisiti rimangono soggetti al prossimo avviso del fornitore.
CVE-2026-109618 e CVE-2026-109619 possono ancora colpirmi nel 2026?
Sì. Al momento della scrittura, il 21 ottobre 2026, il rilascio di sicurezza d’emergenza è programmato per le 14:00 UTC e le vulnerabilità restano non corrette nelle versioni attualmente distribuite. I ricercatori hanno affermato che le versioni PHP risalenti a PHP 5 potrebbero essere colpite, ma PHP non ha ufficialmente confermato questa gamma di versioni. Le organizzazioni dovrebbero inventariare tutte le distribuzioni e utilizzare il prossimo avviso del fornitore per determinare l’effettiva esposizione.
Come posso proteggermi da CVE-2026-109618 e CVE-2026-109619?
Prepararsi a installare gli aggiornamenti di sicurezza PHP immediatamente quando vengono rilasciati, dando priorità ai server esposti a Internet. Inventariare le installazioni PHP, inclusi i runtime integrati con le applicazioni e gli apparecchi, e identificare i sistemi che eseguono branche giunte a fine vita. Fino a quando le correzioni non vengono distribuite, aumentare il monitoraggio per processi PHP figlio inusuali e esecuzioni di comandi lato server. I sistemi che non possono essere patchati tempestivamente dovrebbero avere l’esposizione esterna ridotta o, dove operativo possibile, essere temporaneamente isolati. Se viene trovata attività sospetta, isolare il server e conservare la telemetria web, PHP, endpoint e di rete per un’indagine forense.