CVE-2026-109618 non è un codice da programmatori. È un allarme per chi ha un sito in PHP

Cosa è successo il 21 ottobre 2026

Il 21 ottobre 2026 il CSIRT Italia, la squadra di risposta agli incidenti dell'Agenzia per la cybersicurezza nazionale (ACN), ha pubblicato l'alert AL07/261021/CSIRT-ITA: due vulnerabilità critiche in PHP, entrambe con punteggio 9,2 su 10, chiamate PHP2Shell. Il 23 ottobre l'ha aggiornato, segnalando la presenza di exploit dimostrativi funzionanti, cioè programmi che approfittano davvero della falla.

Il giorno prima, il 20 ottobre, il sito ufficiale php.net aveva dato un preavviso: un aggiornamento di sicurezza critico sarebbe uscito il giorno dopo alle 14:00 UTC, cioè alle 16:00 ora italiana. I dettagli non erano pubblici e tutti gli utenti di PHP erano invitati a prepararsi. Il segreto non ha retto fino in fondo: informazioni sulle due falle sono circolate online prima dell'ora prevista, e Amazon ha poi riferito che uno dei suoi server esca aveva registrato già il 17 ottobre un tentativo di sfruttamento, cioè di uso effettivo della falla. Lo stesso 21 ottobre la CISA statunitense ha chiesto l'aggiornamento immediato e le istituzioni europee per la cybersicurezza hanno pubblicato una dichiarazione congiunta.

Le due vulnerabilità hanno codici ufficiali: CVE-2026-109618 e CVE-2026-109619. Se hai un sito in WordPress, WooCommerce, Magento, Drupal o Laravel, ti riguardano direttamente, perché girano tutti su PHP. La parte scomoda: la correzione non si installa da sola e, su un hosting condiviso, non la installi neppure tu. La installa chi gestisce il server.

Per sapere cosa fare servono tre cose: capire se la tua versione di PHP è colpita, sapere chi gestisce il tuo server e capire cosa ti dice davvero un codice CVE. Partiamo dalla prima, perché è quella che ti dice se hai fretta.

Il tuo sito è esposto? — versioni PHP colpite e corrette, anche con WordPress

La risposta breve: sì, se il sito gira su PHP, cioè quasi certamente, se è fatto con WordPress o con una piattaforma simile (un CMS, sistema di gestione dei contenuti). La risposta lunga dipende dalla versione.

Il problema grosso sono i rami vecchi. Per PHP 8.1 e precedenti il progetto non pubblica più versioni. Per 7.4, 8.0 e 8.1 il team di sicurezza ha comunque messo a disposizione correzioni minime nel codice sorgente, per chi compila PHP da sé, e alcune distribuzioni Linux e fornitori di supporto esteso distribuiscono pacchetti corretti. Per la 7.3 e precedenti il team di PHP non ha pubblicato nulla, anche se Wiz sostiene che le vulnerabilità risalgono fino a PHP 5.4, del 2012.

Attenzione anche all'8.2: ha la versione corretta, 8.2.35, ma il supporto di sicurezza finisce il 31 dicembre 2026. Il passaggio all'8.3 o successive conviene pianificarlo da subito.

I numeri vengono da W3Techs, che può contare solo i siti di cui la versione si vede da fuori: non sono un censimento. Indicano però una direzione chiara: il 48,3% dei siti PHP misurati usa un ramo per cui il progetto PHP non ha pubblicato una versione corretta. Non significa che siano tutti vulnerabili, perché alcuni hanno ricevuto correzioni dalla distribuzione o dall'hosting. Significa che non lo puoi sapere senza chiedere.

Una trappola frequente è il numero di versione. Su Ubuntu 24.04, per esempio, il PHP corretto non compare come 8.3.36 ma come pacchetto 8.3.6-0ubuntu0.24.04.13, indicato da Ubuntu per CVE-2026-109618: la distribuzione ha inserito la correzione nella sua versione senza cambiare il numero principale. Su Ubuntu 22.04 PHP 8.1 ha ricevuto il pacchetto corretto 8.1.2-1ubuntu2.28, anche se il progetto PHP non pubblica più versioni per l'8.1. Un «8.3.6» sul server non è per forza una cattiva notizia, e «8.3.36» non è l'unico numero buono.

E per WordPress e WooCommerce: aggiornare tema e plugin non risolve PHP2Shell. Cloudflare lo scrive chiaramente nella sua analisi: il problema è in PHP, quindi va aggiornato il PHP che fa girare l'applicazione.

E PHP non sta solo nei siti. La dichiarazione congiunta del 21 ottobre di Commissione europea, ENISA, CERT-EU, Europol (EC3) e rete dei CSIRT nazionali avverte che molti prodotti commerciali e open source usano PHP dietro le quinte e possono essere colpiti anche se non sembrano usarlo. Il centro nazionale per la cybersicurezza dei Paesi Bassi (NCSC-NL) tiene un elenco pubblico di questi prodotti. La dichiarazione raccomanda di aggiornare per primi i sistemi esposti su internet e, dove non è possibile subito, di isolare le applicazioni esposte dalle reti pubbliche.

Due porte lasciate aperte nel motore — cos'è PHP2Shell, la vulnerabilità critica di PHP

PHP2Shell è il nome pubblico di due vulnerabilità critiche nel motore di PHP, CVE-2026-109618 e CVE-2026-109619, che possono permettere a un attaccante senza account di eseguire codice sul server di un sito.

PHP è il linguaggio di programmazione che gira sul server e costruisce le pagine prima che arrivino nel browser del visitatore. Su PHP sono costruiti WordPress, WooCommerce, Magento e Drupal. Secondo W3Techs, il 23 ottobre 2026 lo usava il 69,3% dei siti di cui si riesce a identificare il linguaggio lato server.

Una shell è la riga di comando di un server, il posto in cui l'amministratore scrive le istruzioni. Nel gergo della sicurezza, «ottenere una shell» vuol dire poter dare ordini al server come se ne fossi l'amministratore. Il nome ricorda Log4Shell (2021) e React2Shell (2025), altre vulnerabilità con «shell» nel nome, che anch'esse davano accesso al server.

In concreto, sono due errori diversi nel modo in cui PHP gestisce la memoria.

• CVE-2026-109618, esecuzione di codice tramite corruzione della memoria. Quando PHP resta senza memoria a metà di una richiesta, la abbandona di colpo. Alcuni dati restano preparati a metà e, nella pulizia finale, possono essere trattati come validi. Un attaccante che provoca apposta l'esaurimento della memoria, per esempio con una richiesta di caricamento file costruita ad arte, può infilarci le sue istruzioni. È come un cameriere che, rimasto senza vassoi a metà ordinazione, lascia la comanda scritta a metà; a fine turno la cassa la legge come un ordine completo.
• CVE-2026-109619, esecuzione di codice tramite stato rimasto indietro. PHP conserva alcune informazioni da una richiesta all'altra. A volte puntano a memoria già liberata, e la richiesta successiva gestita dallo stesso processo le può usare prima che vengano azzerate. È come una camera d'albergo consegnata al nuovo ospite con i biglietti del precedente ancora sul comodino.

Due dettagli rendono PHP2Shell più serio della media. Il primo: non dipende dal codice del tuo sito. Wiz, una delle società che hanno scoperto le vulnerabilità, scrive che persino un'applicazione «Hello World», la pagina più semplice possibile, può essere vulnerabile su una versione colpita. Il secondo: sui server Apache con il modulo mod_php il team di PHP ha dimostrato un attacco che parte prima che venga eseguita una sola riga dell'applicazione, ed è lì che considera il rischio più alto.

Secondo l'avviso ufficiale sono colpite tutte le installazioni PHP che servono pagine web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Non serve sapere quale hai: sono tutte colpite. L'impatto confermato è l'esecuzione di codice con i permessi del processo web, cioè accesso ai file del sito e, di solito, anche a quelli in cui stanno le password del database. RCE (remote code execution, esecuzione di codice da remoto) vuol dire proprio questo: l'attaccante non indovina la tua password, fa eseguire i suoi comandi al server.

Il numero di richiamo del software — cos'è una CVE

Una CVE è un identificatore pubblico e univoco, nella forma CVE-ANNO-NUMERO, assegnato a una vulnerabilità informatica nota, perché chiunque nel mondo possa riferirsi esattamente allo stesso problema.

La sigla viene dall'inglese Common Vulnerabilities and Exposures, cioè «vulnerabilità ed esposizioni comuni». Una vulnerabilità è un errore in un programma che qualcuno può usare per fare ciò che non dovrebbe: leggere dati, entrare senza password, prendere il controllo.

Il paragone più semplice è il richiamo di un'auto. Quando un costruttore scopre un difetto ai freni, la campagna di richiamo ha un numero, e costruttore, officina, assicurazione e proprietario parlano dello stesso numero senza descrivere ogni volta il difetto. Una CVE fa la stessa cosa per il software: l'hosting, il produttore, lo scanner di sicurezza e il CSIRT nazionale dicono «CVE-2026-109618» e sanno tutti di cosa si parla.

Il programma CVE esiste dal 1999. È gestito da MITRE, un'organizzazione statunitense senza scopo di lucro, e finanziato dalla CISA, l'agenzia americana per la cybersicurezza. I codici però non li assegna un solo ente. Il 23 ottobre 2026, secondo le statistiche di cve.org, li assegnavano 559 organizzazioni di 43 paesi, chiamate CNA (CVE Numbering Authorities, autorità di numerazione): produttori di software, società di sicurezza, squadre nazionali di risposta agli incidenti.

Una cosa che cve.org dice esplicitamente: la CVE non è un database, è un sistema di nomi. I dettagli tecnici, i punteggi e le correzioni stanno altrove: negli avvisi del produttore e in due database pubblici, lo statunitense NVD (National Vulnerability Database) e l'europeo EUVD (European Vulnerability Database), dell'ENISA, l'agenzia dell'Unione europea per la cybersicurezza. Nell'EUVD i due codici di PHP2Shell compaiono come EUVD-2026-107260 ed EUVD-2026-107265.

Anche il volume dice qualcosa. Nel 2025 sono stati pubblicati 48.244 record CVE, in media più di 130 al giorno. Nei primi sei mesi del 2026 sono stati 35.872, quasi 200 al giorno. Il titolare di un'attività non può leggere 200 avvisi al giorno, e non deve: gli serve sapere in fretta quali lo riguardano.

Anno, numero e cosa non dice — come si legge un codice CVE

Prendiamo CVE-2026-109618, la prima delle due vulnerabilità. Ha tre parti.

• CVE è il prefisso fisso: dice solo che è un identificatore del programma CVE.
• 2026 è l'anno del codice. Dipende da quando il codice è stato riservato o reso pubblico, non dalla data della scoperta. Con PHP2Shell le due cose cadono nello stesso anno: la falla è stata trovata ad agosto 2026 e pubblicata a ottobre.
• 109618 è il numero progressivo, di almeno quattro cifre. Non è una classifica e nemmeno il numero di vulnerabilità dell'anno: è solo il numero riservato per questo codice.

Accanto al codice, un record CVE contiene una descrizione, i prodotti colpiti e i link agli avvisi ufficiali. Può avere anche uno stato: RESERVED (riservato, dettagli non ancora pubblici), DISPUTED (contestato, qualcuno non è d'accordo che sia una vulnerabilità) o REJECTED (respinto, da ignorare). E due cose il codice non te le dice: quanto è grave il problema e se riguarda te. Per la prima c'è il punteggio CVSS; per la seconda devi conoscere la tua versione.

Quanto è grave? — il punteggio CVSS spiegato con PHP2Shell

CVSS sta per Common Vulnerability Scoring System, il sistema comune di valutazione delle vulnerabilità. Lo cura FIRST, il forum internazionale delle squadre di risposta agli incidenti, e dà a ogni vulnerabilità un voto da 0 a 10. I voti di PHP2Shell usano la versione 4.0 del sistema. Pensalo come il triage del pronto soccorso: ti dice quanto è grave il caso, non se il paziente sei tu.

Il voto nasce da una stringa che descrive l'attacco. Per entrambe le vulnerabilità gli avvisi ufficiali di PHP riportano la stessa: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Sembra una password, ma si legge pezzo per pezzo: AV:N, l'attacco arriva dalla rete, quindi da qualsiasi punto di internet; PR:N e UI:N, non servono un account né un tuo clic; VC:H, VI:H, VA:H, se riesce l'impatto sul server è alto: può leggere dati, modificarli e fermare il servizio.

Restano AC:H, attacco difficile, perché secondo la specifica FIRST il successo dipende dall'aggirare protezioni già presenti sul server, e AT:P, perché servono condizioni di configurazione e di esecuzione che non ci sono ovunque. Dicono che l'attacco non è banale, ma il voto resta nella fascia critica. E «difficile» non vuol dire «impossibile»: secondo The Register, il 22 ottobre 2026 la società di sicurezza VulnCheck dichiarava di aver costruito in una notte un exploit funzionante per CVE-2026-109618.

L'exploit funziona su PHP 8.4.26, una versione non corretta, con le impostazioni consigliate per la produzione, e aggira l'ASLR, una protezione standard che dispone a caso gli indirizzi della memoria. Non è pubblico, e proprio VulnCheck avverte di non confondere la difficoltà tecnica con una protezione.

Grave non vuol dire attaccato — EPSS e catalogo KEV

Il CVSS misura quanto danno può fare una vulnerabilità, non quanto è probabile che venga usata. Per questo ci sono altri due strumenti, entrambi gratuiti.

EPSS (Exploit Prediction Scoring System) è un altro progetto FIRST: stima la probabilità che una vulnerabilità venga sfruttata nei 30 giorni successivi. Il 22 ottobre 2026 CVE-2026-109618 aveva il 5,3% e CVE-2026-109619 il 5,8%. Sembra poco, ma le metteva sopra il 92–93% di tutte le vulnerabilità valutate da EPSS.

KEV (Known Exploited Vulnerabilities) è il catalogo della CISA con le vulnerabilità di cui l'agenzia ha prove di sfruttamento reale. Il 23 ottobre 2026 aveva 1.754 voci e PHP2Shell non c'era. Nell'alert del 21 ottobre la CISA scriveva di non aver osservato sfruttamenti al momento della pubblicazione.

La sfumatura che conta: un tentativo di attacco non è un attacco riuscito. Amazon ha visto un tentativo il 17 ottobre su un honeypot, cioè un server lasciato apposta in vista per attirare gli attaccanti e studiarne i metodi. watchTowr dice di aver osservato lo sfruttamento di entrambe le vulnerabilità dal 21 ottobre, sempre nella sua rete di server esca, senza dire se ci siano state compromissioni. E Sansec scriveva il 22 ottobre che gli exploit pubblici non funzionano su un'installazione PHP predefinita e che lo sfruttamento di massa sembra meno probabile di quanto si temesse il giorno del rilascio. Possono essere vere tutte e tre le cose insieme. La conclusione pratica non cambia: si aggiorna.

Da agosto al 23 ottobre — la cronologia di PHP2Shell

La cronologia mostra come vive di solito una CVE: scoperta, segnalazione riservata al produttore, correzione sotto embargo, cioè un periodo in cui i dettagli restano segreti finché la correzione non c'è, poi pubblicazione simultanea. Con PHP2Shell il segreto non ha retto fino in fondo: i dettagli sono trapelati il 20 ottobre, il giorno prima della pubblicazione.

Una data da ricordare: il 17 ottobre. Amazon consiglia di far partire le indagini da lì, non dalla data di pubblicazione. Se gestisci da solo il tuo server, è da lì che inizi a guardare i log.

Due messaggi dagli hosting — come si riconosce un hosting gestito che sta sul pezzo

Il bello di una CVE è che chiunque la può seguire. Un fornitore di hosting serio lo fa al posto tuo: ha persone che leggono gli avvisi, sa quali versioni girano sui suoi server e ti dice, prima che tu chieda, se devi fare qualcosa. Dopo il rilascio delle correzioni abbiamo ricevuto due messaggi di questo tipo, in rumeno, che traduciamo. Non facciamo i nomi dei fornitori: ci interessa il tipo di messaggio.

Il primo è apparso come finestra nell'area clienti. Citava i due codici, CVE-2026-109618 e CVE-2026-109619, diceva che il fornitore aveva aggiornato alle versioni di PHP con le correzioni tutti i server con un'opzione attiva di assistenza tecnica e gestione, e si chiudeva con la frase che ogni cliente vuole leggere:

«Non è necessaria alcuna azione da parte Sua.»

È breve e c'è tutto: nomina il problema, dice cosa è stato fatto e chi non deve fare niente. E ha un dettaglio facile da perdere: l'aggiornamento automatico riguardava i server con gestione. Chi ha un server non gestito, di solito un VPS (server privato virtuale) che amministra da sé, dallo stesso fornitore riceve solo l'infrastruttura. Lì aggiornare PHP tocca a lui.

Il secondo era un annuncio nel portale clienti, datato mercoledì 21 ottobre 2026. Il fornitore scriveva di essere al corrente delle vulnerabilità di PHP e di monitorare costantemente la pubblicazione degli aggiornamenti rilevanti. Poi descriveva due fasi: le misure di sicurezza necessarie erano state applicate a livello di server, insieme alle patch già disponibili; sarebbero seguite le patch specifiche per ciascuna versione di PHP in uso, man mano che fossero disponibili.

Meno spettacolare, ma onesto: dice apertamente che la correzione ha più fasi e che alcune versioni di PHP l'avrebbero ricevuta dopo il 21 ottobre. Su un server che offre più versioni di PHP le correzioni possono arrivare a scaglioni, alcune direttamente da PHP, altre dalle distribuzioni o dai produttori dei pannelli di hosting. Il messaggio non descrive le misure prese a livello di server, quindi chi usa una versione non ancora corretta fa bene a chiedere quando tocca alla sua.

Dai due messaggi si ricava una lista breve. Davanti a una CVE critica, un buon messaggio dell'hosting:

• nomina il problema, idealmente con i codici CVE, non solo «un problema di sicurezza»;
• dice cosa è già stato fatto e quando;
• dice cosa segue, se la correzione ha più fasi;
• dice chiaramente chi deve fare qualcosa e chi no.

È questa la differenza pratica fra un hosting gestito e uno che amministri da solo. Non che un buon fornitore non abbia mai vulnerabilità: le hanno tutti, perché le ha PHP. Ma qualcuno le segue al posto tuo, e tu lo scopri da un messaggio di tre righe, non da un titolo di giornale. Una trattoria fiorentina con il sito in WordPress su un hosting gestito, in un caso così, ha un solo compito: leggere quel messaggio. Se al 23 ottobre 2026 dal tuo fornitore non è arrivato niente, il messaggio della sezione successiva ti porta via un minuto.

Cosa fare oggi, in quest'ordine — come controllare la versione PHP e cosa chiedere all'hosting

I primi tre passi e l'ultimo sono per te. I passi 4–6 sono per chi gestisce il server: tu, se hai un server tuo, oppure il fornitore di hosting.

1. Scopri quale versione di PHP usa il sito. In cPanel o Plesk di solito vedi solo il ramo, per esempio 8.3, non l'ultima cifra. La versione completa la vedi in WordPress, nella pagina Salute del sito (Site Health), scheda Info, sezione Server, oppure la chiedi al tuo hosting.
2. Confrontala con la tabella qui sopra. 8.5.12, 8.4.27, 8.3.36, 8.2.35 o successive vogliono dire versione corretta. Un numero più basso non è per forza un problema, se l'hosting conferma un pacchetto con la correzione inclusa.
3. Su hosting gestito o condiviso, leggi i messaggi del fornitore. Se non hai ricevuto niente, chiedi conferma per iscritto, con il messaggio qui sotto.
4. Su un server gestito da te, si aggiornano i pacchetti PHP e si riavviano tutti i processi PHP. Un processo non riavviato continua a eseguire il vecchio codice dalla memoria.
5. Se non si può aggiornare subito, si applicano le misure temporanee dell'avviso di php.net e si mette davanti un firewall per applicazioni web (WAF, un filtro davanti al sito). Le misure temporanee riducono il rischio, non lo eliminano; l'elenco esatto è nell'avviso ufficiale. Il CSIRT Italia, in quel caso, consiglia di valutare la sospensione dei siti con versioni vulnerabili.
6. Si controllano i log del server, a partire dal 17 ottobre. I segnali indicati da Wiz e Amazon: richieste insolite di caricamento file seguite da errori di memoria o da errori 500 ripetuti, cookie di sessione (PHPSESSID) insolitamente grandi e richieste che contengono la stringa PHP_SESSION_UPLOAD_PROGRESS. Se compaiono, si avvisa subito l'hosting o l'amministratore e si conservano i log.
7. Controlla il backup. Non è una difesa contro PHP2Shell: è il piano per il caso in cui qualcosa sia già passato.

Cosa è e cosa non è ogni termine — glossario CVE, CVSS, EPSS, KEV, RCE

Negli avvisi di sicurezza i termini si mescolano facilmente. La tabella li mette uno accanto all'altro, con quello che fa ciascuno e, soprattutto, quello che non fa.

Un esempio di WAF che ha contato: Cloudflare ha attivato regole per PHP2Shell il 21 ottobre alle 03:02 UTC, più di 10 ore prima del rilascio delle versioni corrette, anche per i clienti del piano gratuito. Aiuta, ma proprio Cloudflare scrive che va aggiornato PHP e consiglia di lasciare acceso il firewall durante l'aggiornamento. Se vuoi capire cosa fa un firewall come quello di Cloudflare, ne abbiamo parlato in Cloudflare spiegato semplice.

L'AI ha trovato la falla. Cosa vuol dire per te — più CVE, più spesso

PHP2Shell ha anche un lato nuovo. La società di sicurezza Calif ha trovato la prima vulnerabilità ad agosto 2026, durante un audit del codice sorgente di PHP finanziato da OpenAI con il programma Patch the Planet, lavorando con il modello GPT-5.6 Sol. Wiz è arrivata in modo indipendente agli stessi problemi qualche settimana dopo, con GPT-5.6 Sol, con Gemini 4 Argon di Google e con strumenti propri. Cloudflare elenca chi li ha segnalati: Calif, Wiz, OpenAI e Quarkslab.

Non è una macchina che ha trovato la falla da sola. Le persone di Calif e Wiz hanno usato l'AI come strumento, e Calif dice, citata da The Next Web, che nessun modello tira fuori «tutti gli errori» con istruzioni semplici. Wiz scrive che i modelli hanno ridotto molto lo sforzo di adattare gli exploit a versioni, configurazioni e disposizioni di memoria diverse.

Non sappiamo quanta parte della crescita delle CVE venga dall'AI. Sappiamo che il volume è cresciuto: quasi 200 al giorno nella prima metà del 2026, contro circa 132 al giorno nel 2025. Per chi ha un'attività la conclusione è semplice: gli aggiornamenti di sicurezza diventano routine, non eventi. Conta meno seguire ogni avviso e più avere qualcuno, in azienda o nell'hosting, che li segue per te.

Tre soglie, in quest'ordine

Non è una conclusione, è un triage. Ti fermi alla prima soglia che non superi.

Prima soglia: sai quale versione di PHP usa il tuo sito? Se no, scoprila da WordPress o chiedila al tuo hosting. Senza la versione, ogni avviso è solo rumore.

Seconda soglia: la versione è corretta? 8.5.12, 8.4.27, 8.3.36, 8.2.35 o successive, oppure un pacchetto confermato dal fornitore. Se sei su PHP 8.1 o precedenti, questa soglia è anche una domanda sulla migrazione: i rami vecchi non ricevono più versioni ufficiali, per nessuna CVE.

Terza soglia: chi lo viene a sapere per primo, alla prossima CVE? Se la risposta è «io, dai giornali», hai un rischio che non dipende da PHP. L'hosting, un amministratore o un fornitore dovrebbero saperlo prima di te e dirti se devi fare qualcosa.

Nell'hosting gestito di Cittago i server sono seguiti da persone al corrente di avvisi come questo, e gli aggiornamenti di sicurezza del server non sono un compito del cliente. Se vuoi che non sia più un tuo pensiero, è di questo che si occupa il nostro hosting gestito. Non hai bisogno di noi se il tuo fornitore ti ha già confermato, per iscritto, che il server è aggiornato: vuol dire che sta facendo esattamente ciò che serve.

Ne riparliamo tra 3–6 mesi 😉

Domande con risposte che riteniamo utili

Le domande che vengono naturali a chi ha visto un codice CVE in un avviso e vuole capire se lo riguarda.

Ultimo aggiornamento: 23 ottobre 2026. Gli avvisi di PHP (php.net e GitHub), l'alert del CSIRT Italia, l'alert della CISA, le statistiche di cve.org, il catalogo KEV, i punteggi EPSS, i record EUVD, la pagina di Ubuntu e i dati W3Techs sono stati letti il 22 e il 23 ottobre 2026. I due messaggi dei fornitori di hosting li abbiamo ricevuti noi, in rumeno, e li riportiamo tradotti; non facciamo i nomi dei fornitori. Cosa è cambiato con l'aggiornamento del 23 ottobre 2026: abbiamo aggiunto la dichiarazione congiunta UE del 21 ottobre e l'elenco NCSC-NL dei prodotti che contengono PHP, i link alle fonti ufficiali direttamente nel testo e l'ora del rilascio delle correzioni, che varia di poco fra le fonti (13:30–14:00 UTC); abbiamo ricontrollato il catalogo KEV, dove PHP2Shell ancora non compare. La situazione dello sfruttamento cambia in fretta. Aggiorniamo la pagina quando arrivano informazioni nuove.

Fonti: PHP · Avviso di sicurezza (EN) · GitHub · GHSA-w8hw-w9fx-j79w (EN) · GitHub · GHSA-6wmf-4rv5-p3rp (EN) · PHP · Versioni supportate (EN) · ACN · CSIRT Italia, AL07/261021/CSIRT-ITA · CISA · Alert del 21 ottobre (EN) · ENISA · Dichiarazione congiunta UE (EN) · NCSC-NL · Prodotti che contengono PHP (EN) · CISA · Catalogo KEV (EN) · cve.org · FAQ (EN) · cve.org · Statistiche (EN) · FIRST · CVSS 4.0 (EN) · FIRST · EPSS (EN) · ENISA · EUVD-2026-107260 · Amazon · MadPot (EN) · watchTowr · PHP2Shell (EN) · Cloudflare · Regole WAF (EN) · Sansec · PHP2Shell (EN) · Wiz · PHP2Shell (EN) · The Next Web · Calif e OpenAI (EN) · The Register · VulnCheck (EN) · Ubuntu · CVE-2026-109618 (EN) · W3Techs · PHP (EN) · W3Techs · PHP 8 (EN)