PHP2Shell: come aggiornare PHP su cPanel, Plesk e CloudLinux

Il 21 ottobre 2026 il progetto PHP ha pubblicato in via straordinaria quattro nuove versioni del linguaggio per correggere due vulnerabilità che, nelle parole dell'avviso ufficiale, «can allow unauthenticated remote code execution», cioè possono permettere a chiunque di eseguire codice sul server senza autenticarsi e senza che l'applicazione abbia alcuna colpa. Le due falle, registrate come CVE-2026-109618 e CVE-2026-109619 e ribattezzate PHP2Shell dalla comunità di sicurezza, hanno entrambe un punteggio CVSS 4.0 di 9,2, che le colloca nella fascia critica.

Se gestite un server con cPanel, Plesk o CloudLinux, è molto probabile che sopra ci girino più versioni di PHP contemporaneamente, alcune delle quali magari dimenticate da anni perché servono un solo sito che nessuno tocca più. È proprio questa la situazione in cui un aggiornamento fatto di fretta lascia un buco aperto, perché si aggiorna la versione predefinita e ci si scorda delle altre. In questo articolo raccogliamo, pannello per pannello, quali sono le versioni minime che contengono la correzione, come si installano, come si verifica che l'installazione sia andata davvero a buon fine e cosa si può fare se l'aggiornamento non è possibile subito.

Cosa è successo, in ordine

La sequenza degli eventi spiega buona parte dell'urgenza. Secondo la ricostruzione di Huntress, il 20 ottobre un messaggio pubblicato su Hacker News ha anticipato la divulgazione di due vulnerabilità critiche in PHP, e benché il post sia stato rimosso in poco tempo, gli screenshot avevano già iniziato a circolare sui social. Lo stesso giorno il team di sicurezza di PHP ha annunciato una release urgente fissata per il giorno successivo alle 14:00 UTC, anticipando quindi la data concordata in origine.

Le versioni correttive sono uscite come previsto il 21 ottobre e sono la 8.5.12, la 8.4.27, la 8.3.36 e la 8.2.35. I pacchettizzatori delle distribuzioni Linux e i fornitori di supporto esteso, come precisa lo stesso avviso di PHP, avevano ricevuto le patch in anticipo, ed è per questo che nel giro di poche ore sono comparsi i primi pacchetti aggiornati anche per i pannelli di controllo.

Sulla scala del problema basta un dato. Palo Alto Networks, nel suo bollettino di Unit 42, riferisce di aver individuato con la propria telemetria oltre 22,6 milioni di istanze esposte su Internet e potenzialmente vulnerabili, precisando che si tratta di installazioni potenzialmente colpite e non di sistemi compromessi.

Sullo sfruttamento reale le fonti, al momento in cui scriviamo, non concordano, e vale la pena riportarle tutte. watchTowr afferma di aver osservato tentativi di sfruttamento a partire dal 21 ottobre attraverso la propria rete di honeypot. Huntress, nello stesso pomeriggio, scriveva di non aver rilevato attacchi sui sistemi dei propri partner, pur segnalando che altri ricercatori li stavano vedendo emergere. Il CERT-EU non conferma lo sfruttamento attivo, ma osserva che la circolazione di proof of concept rende più probabile che gli attaccanti siano già al lavoro. Per chi deve decidere cosa fare sul proprio server, la conclusione pratica non cambia: si aggiorna adesso.

Come funzionano le due vulnerabilità

Non serve essere sviluppatori del linguaggio per capire il meccanismo, ed è utile capirlo perché spiega sia perché le mitigazioni temporanee funzionano solo in parte, sia perché alcune configurazioni sono più esposte di altre.

CVE-2026-109618, la memoria che finisce nel momento sbagliato

PHP interrompe le richieste che superano il limite di memoria configurato con memory_limit, e lo fa in modo brusco. Il CERT-EU spiega che questa interruzione può avvenire mentre i dati interni della richiesta sono stati inizializzati solo in parte, per esempio durante l'elaborazione di un modulo con caricamento di file. A quel punto la fase di pulizia, che dovrebbe soltanto liberare la memoria usata, tratta come validi dati che non lo sono e finisce per liberare memoria non inizializzata, che può contenere valori scelti dall'attaccante. È da questa confusione che si arriva all'esecuzione di codice.

L'aspetto più insidioso, sottolineato da Rapid7, è che una richiesta multipart costruita ad arte può esaurire la memoria anche rispettando i limiti di dimensione configurati, e che l'exploit dimostrato funziona con i limiti di input e di memoria predefiniti.

CVE-2026-109619, lo stato che sopravvive alla richiesta

La seconda vulnerabilità riguarda il fatto che un processo PHP non serve una sola richiesta e poi muore, ma ne gestisce molte in sequenza. L'avviso ufficiale la descrive così: uno stato interno che appartiene a una richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata, e una richiesta successiva servita dallo stesso processo può usarlo prima che la normale inizializzazione lo azzeri. In gergo si chiama use after free, e il CERT-EU indica gli errori fatali come uno dei modi in cui la pulizia viene saltata.

Rapid7 elenca due percorsi confermati. Il primo passa per i backtrace degli errori fatali introdotti in PHP 8.5 e attivi per impostazione predefinita. Il secondo passa per il monitoraggio dell'avanzamento degli upload legato alle sessioni, una funzione anch'essa attiva per impostazione predefinita e che non richiede nemmeno che l'applicazione chiami session_start(), il che significa che un sito può essere esposto anche se non usa affatto le sessioni.

Figura 1. CVE-2026-109618 colpisce dentro una singola richiesta, CVE-2026-109619 sfrutta il passaggio fra due richieste servite dallo stesso processo.

Perché mod_php è il caso peggiore

L'avviso di PHP elenca come colpite «all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed», quindi nessuna modalità di esecuzione è al riparo. Il rischio però non è uguale per tutte.

Con mod_php, cioè con PHP caricato come modulo dentro Apache, lo sfruttamento può riuscire prima ancora che venga eseguita una sola riga dell'applicazione, perché la pulizia avviene anche quando l'avvio della richiesta fallisce. Rapid7 riporta che mod_php è l'unica configurazione per cui è stata dimostrata l'esecuzione di codice con entrambe le vulnerabilità. PHP-FPM, che è la modalità predefinita sulla maggior parte dei server cPanel e Plesk moderni, termina il processo quando l'avvio fallisce, e questo blocca quella specifica sequenza; resta però vulnerabile al percorso delle sessioni, che è stato validato anche su FPM. Tradotto in pratica, FPM rende l'attacco più difficile ma non impossibile, e chi ha ancora siti serviti con mod_php, situazione che incontriamo spesso su server configurati molti anni fa, deve considerarli la priorità assoluta.

Le versioni corrette, piattaforma per piattaforma

Qui sta la parte che crea più confusione, perché ogni pannello di controllo distribuisce PHP con pacchetti propri, con nomi diversi e, nel caso delle versioni non più supportate, con numeri di versione che non cambiano anche quando la correzione è stata applicata.

PHP ufficiale

Il progetto PHP ha corretto soltanto i rami ancora supportati, cioè dalla 8.2 alla 8.5. Per i rami 7.4, 8.0 e 8.1, che sono a fine vita, il team di sicurezza ha pubblicato dei backport minimali sul repository di PHP, pensati per chi compila da sorgente o non ha un fornitore di supporto esteso, ma non nuove versioni ufficiali. Il CERT-EU conferma che sono colpiti anche la 8.1 e tutti i rami precedenti. Vale la pena ricordare inoltre che PHP 8.2 raggiunge la fine del supporto il 31 dicembre 2026, quindi chi è su quel ramo dovrebbe usare questo aggiornamento come occasione per pianificare il passaggio a una versione più recente.

• PHP 8.5: 8.5.12, release ufficiale del 21 ottobre 2026
• PHP 8.4: 8.4.27, release ufficiale del 21 ottobre 2026
• PHP 8.3: 8.3.36, release ufficiale del 21 ottobre 2026
• PHP 8.2: 8.2.35, release ufficiale, ramo a fine supporto il 31 dicembre 2026
• PHP 8.1, 8.0, 7.4: nessuna release, solo backport minimali nel codice sorgente

C'è un'ultima avvertenza che riguarda chi installa PHP dal repository di Remi, molto diffuso sui server AlmaLinux e Rocky senza pannello: l'avviso ufficiale segnala che rpms.remirepo.net, essendo un progetto volontario, non avrebbe avuto aggiornamenti il giorno del rilascio, e suggerisce di passare ai pacchetti della distribuzione o di compilare da sorgente.

cPanel ed EasyApache 4

Il changelog ufficiale di EasyApache 4 registra le correzioni nella versione 25.91 del 21 ottobre 2026, classificandole come «Two vulnerabilities in PHP (critical)». I pacchetti ea-php82, ea-php83, ea-php84 ed ea-php85 sono stati portati alle versioni ufficiali corrette, mentre ea-php74, ea-php80 ed ea-php81 hanno ricevuto il backport della correzione senza cambiare numero di versione.

• ea-php85: 8.5.12, ticket EA-13607
• ea-php84: 8.4.27, ticket EA-13608
• ea-php83: 8.3.36, ticket EA-13609
• ea-php82: 8.2.35, ticket EA-13610
• ea-php81: 8.1.x con backport, ticket EA-13611
• ea-php80: 8.0.x con backport, ticket EA-13612
• ea-php74: 7.4.x con backport, ticket EA-13613

La conseguenza pratica è che per le versioni 7.4, 8.0 e 8.1 il comando php -v non vi dirà nulla di utile, perché mostrerà lo stesso numero di prima, e la verifica va fatta sul changelog del pacchetto, come vedremo più avanti. Le versioni 7.3 e precedenti non compaiono nel changelog di cPanel, quindi sui server cPanel che non girano su CloudLinux vanno considerate senza correzione.

CloudLinux: alt-php, ea-php e PHP nativo

CloudLinux è il caso più articolato perché sullo stesso server convivono tre famiglie di pacchetti PHP, e il blog ufficiale di CloudLinux, aggiornato più volte fra il 21 e il 22 ottobre, le tratta separatamente.

La prima famiglia sono i pacchetti alt-php, quelli che alimentano PHP Selector e che vivono sotto /opt/alt/. Dalle 01:25 UTC del 22 ottobre le versioni corrette sono nel repository stabile per tutti i rami, dalla 5.2 alla 8.5, su CloudLinux 7, 8 e 9. Su CloudLinux 10 i rami dalla 5.3 alla 8.5 arrivano dal repository TuxCare ELS, mentre la 5.2 arriva dai repository CloudLinux, e su CloudLinux per Ubuntu 22.04 la correzione copre la 5.2, la 5.6 e i rami dalla 7.0 alla 8.5. Per CloudLinux 6, al momento dell'ultimo aggiornamento del blog, la disponibilità non era ancora confermata. È un punto di forza notevole di CloudLinux, perché è l'unica delle tre piattaforme che corregge anche i rami 5.x e 7.x più vecchi.

La seconda famiglia sono i pacchetti ea-php che CloudLinux ricompila per i server cPanel, e qui c'è un dettaglio che può trarre in inganno. CloudLinux ha rilasciato versioni corrette per tutti i rami da ea-php52 a ea-php85 applicando la patch alle versioni esistenti, il che significa che il numero di versione può restare più basso di quello ufficiale: il blog porta l'esempio di ea-php84, che su CloudLinux resta alla 8.4.26 pur contenendo la correzione. Chi controlla soltanto il numero di versione potrebbe concludere che il server è vulnerabile quando non lo è, oppure, peggio, il contrario.

La terza famiglia è il PHP nativo dei repository di sistema, quello installato in /usr/bin/php. Qui la distribuzione è più lenta: al 22 ottobre risultavano nel repository stabile soltanto PHP 8.2 e 8.3 su CloudLinux 9 e PHP 8.2 su CloudLinux 8, mentre gli altri rami erano in distribuzione graduale.

• alt-php dalla 5.2 alla 8.5: su CloudLinux 7, 8, 9, corretti, repository stabile
• alt-php dalla 5.2 alla 8.5: su CloudLinux 10, corretti, in parte da TuxCare ELS
• alt-php: su CloudLinux per Ubuntu 22.04, corretti, repository stabile
• alt-php: su CloudLinux 6, non ancora confermato
• da ea-php52 a ea-php85: su CloudLinux 7, 8, 9, 10, corretti con backport, versione invariata
• PHP nativo 8.2 e 8.3: su CloudLinux 9, corretti, repository stabile
• PHP nativo 8.2: su CloudLinux 8, corretto, repository stabile
• PHP nativo, altri rami: su CloudLinux 7, 8, 9, 10, distribuzione graduale

Plesk

L'articolo di supporto di Plesk dedicato alle due vulnerabilità indica che su Linux i rami supportati sono stati aggiornati alle versioni ufficiali, cioè 8.2.35, 8.3.36, 8.4.27 e 8.5.12, e che i rami a fine vita 7.4, 8.0 e 8.1 sono stati ricompilati con la correzione mantenendo lo stesso numero di versione, ovvero 7.4.33, 8.0.30 e 8.1.34. La tabella di Plesk li distingue soltanto per la data di compilazione: sono vulnerabili le build precedenti al 21 ottobre 2026 e corrette quelle compilate quel giorno, quindi anche qui quello che conta è la data della build e non il numero. Su Windows sono state rilasciate le stesse versioni ufficiali per i rami dalla 8.2 alla 8.5, mentre per le versioni più vecchie ancora presenti su molti server, cioè la 5.6, la 7.2 e la 7.3, Plesk non pubblica correzioni e rimanda al servizio a pagamento TuxCare Extended Lifecycle Support for PHP.

C'è poi un componente che molti dimenticano, cioè il PHP che fa funzionare l'interfaccia di Plesk stessa, chiamato sw-engine, che lo stesso articolo di Plesk elenca fra i prodotti colpiti sia su Linux sia su Windows. Sono vulnerabili Plesk Obsidian 18.0.80 fino all'Update 10 compreso e 18.0.81 fino all'Update 3 compreso, mentre la correzione è contenuta in 18.0.80 Update 11 e in 18.0.81 Update 4. Poiché l'interfaccia del pannello è spesso raggiungibile da Internet, è un componente da aggiornare con la stessa urgenza dei siti.

Figura 2. Le versioni minime che contengono la correzione. Dove il numero non cambia, la verifica va fatta sul changelog o sulla data di compilazione del pacchetto.

Avete un server cPanel, Plesk o CloudLinux e non sapete da dove cominciare? Possiamo occuparcene noi: inventario delle versioni installate, aggiornamento, verifica pacchetto per pacchetto e controllo degli indicatori di compromissione. Contattateci o chiamate lo 051 021 7656 e vi diciamo subito come intervenire sul vostro caso.

Come aggiornare, pannello per pannello

Prima di lanciare qualsiasi comando conviene sapere cosa c'è sul server, perché l'obiettivo è aggiornare tutte le versioni di PHP installate e non soltanto quella predefinita. Un sito associato in MultiPHP Manager o in PHP Selector a una versione rimasta indietro resta vulnerabile anche se tutto il resto è aggiornato.

Su cPanel

L'inventario delle versioni installate si ottiene elencando i pacchetti EasyApache:

rpm -qa 'ea-php*-php-cli' | sort
ls /opt/cpanel/ | grep ea-php

L'aggiornamento vero e proprio, nella forma indicata da CloudLinux per i server cPanel, consiste nel ripulire la cache dei repository, aggiornare tutti i pacchetti ea-php e riavviare sia Apache sia i processi PHP-FPM gestiti da cPanel:

yum clean all
yum update "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Sui sistemi più recenti yum è un alias di dnf, quindi il comando funziona in entrambi i casi. Il riavvio non è un dettaglio: finché i processi PHP vecchi restano in memoria continuano a servire richieste con il codice vulnerabile, anche se il pacchetto sul disco è già stato sostituito.

Su CloudLinux con PHP Selector

Per i pacchetti alt-php il blog di CloudLinux indica comandi diversi a seconda della versione del sistema:

# CloudLinux 7
yum clean all
yum update 'alt-php*'
# CloudLinux 8, 9 e 10
dnf clean all
dnf upgrade 'alt-php*'
# CloudLinux per Ubuntu 22.04
apt-get update && apt-get upgrade

Se nelle ore immediatamente successive al rilascio avevate aggiunto il repository TuxCare ELS come soluzione temporanea, CloudLinux spiega che su CloudLinux 7, 8 e 9 lo si può disattivare dopo l'aggiornamento, con yum-config-manager --disable php-els sulla 7 e con dnf config-manager --set-disabled php-els sulla 8 e sulla 9. Su CloudLinux 10 invece va lasciato attivo, perché è proprio da lì che arrivano i pacchetti alt-php.

Sui server che hanno sia cPanel sia CloudLinux bisogna aggiornare entrambe le famiglie, ea-php* e alt-php*, perché gli account impostati su «native» in PHP Selector usano i pacchetti EasyApache e gli altri usano quelli di /opt/alt/. Dopo l'aggiornamento va riavviato PHP-FPM o il web server.

Su Plesk

Su Plesk conviene partire dall'elenco degli handler PHP configurati, che mostra tutte le versioni installate e quelle effettivamente in uso:

plesk bin php_handler --list

L'aggiornamento dei componenti PHP distribuiti da Plesk si fa dall'interfaccia, in Strumenti e impostazioni, Aggiornamenti, oppure da riga di comando con l'installer, come indicato anche nella guida di MassiveGRID:

plesk installer --select-release-current --upgrade-installed-components

Dopo l'aggiornamento vanno riavviati i servizi FPM di ciascuna versione, che su Plesk hanno un nome del tipo plesk-php83-fpm, e fatti rileggere gli handler:

systemctl restart plesk-php83-fpm
plesk bin php_handler --reread

Per sw-engine, cioè il PHP dell'interfaccia, serve invece portare Plesk all'aggiornamento che contiene la correzione, quindi 18.0.81 Update 4 o 18.0.80 Update 11, cosa che avviene da sola se gli aggiornamenti automatici del pannello sono attivi.

La verifica, che è la parte che si salta più spesso

Un aggiornamento che non è stato verificato non è un aggiornamento, ed è qui che le particolarità dei pannelli descritte sopra fanno la differenza. Per le versioni che hanno ricevuto un nuovo numero, basta controllare che php -v di ciascuna versione mostri la release corretta. Su cPanel si può fare per tutte le versioni installate con un solo ciclo:

for p in /opt/cpanel/ea-php*/root/usr/bin/php; do "$p" -v | head -1; done

Per le versioni che hanno ricevuto un backport senza cambiare numero, cioè le 7.4, 8.0 e 8.1 su cPanel, tutti gli ea-php su CloudLinux e i rami a fine vita su Plesk, bisogna guardare dentro il pacchetto. Il blog di CloudLinux suggerisce di cercare i due identificativi nel changelog RPM:

rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

Se il comando restituisce le due righe la correzione è presente, se non restituisce nulla il pacchetto è ancora quello vecchio. Su Plesk con sistemi della famiglia Red Hat la data di compilazione si legge con rpm -qi, e deve essere uguale o successiva al 21 ottobre 2026. Infine, va controllato che non siano rimasti in esecuzione processi PHP avviati prima dell'aggiornamento, perché sono quelli che continuano a eseguire il codice vecchio.

Figura 3. La procedura completa. Il riavvio e la verifica sul pacchetto sono i due passaggi che più spesso vengono saltati.

Se non potete aggiornare subito

Ci sono situazioni in cui l'aggiornamento immediato non è praticabile, per esempio perché un'applicazione vecchia non è stata provata con la nuova build, oppure perché il pacchetto per la vostra piattaforma non è ancora disponibile. L'avviso di PHP propone alcune misure temporanee, ma è esplicito nel dire che riducono l'esposizione a percorsi specifici e non rendono l'installazione sicura.

Per CVE-2026-109619 la misura principale è disattivare il monitoraggio dell'avanzamento degli upload, impostandolo nel php.ini o nella configurazione del pool FPM, perché un ini_set() dentro l'applicazione o un file .user.ini arrivano troppo tardi, quando la richiesta è già stata analizzata:

session.upload_progress.enabled = 0

Su PHP 8.5 si aggiunge fatal_error_backtraces = 0, e in entrambi i casi tutti i processi PHP vanno riavviati perché la modifica abbia effetto.

Per CVE-2026-109618 le indicazioni dell'avviso ufficiale sono meno intuitive. Si suggerisce di impostare memory_limit = -1 in modo che le applicazioni non possano sovrascriverlo, per esempio con php_admin_value nel pool FPM, di ridurre post_max_size a 8M, o a 32M se servono caricamenti di file, mantenendo upload_max_filesize sotto quel valore, e di imporre a livello di web server o di proxy dei limiti sulla dimensione delle richieste, sul numero di campi e sul numero di parti multipart. Va invece evitato l'uso di RLIMIT_AS e RLIMIT_DATA, perché possono essere proprio loro a provocare il fallimento di allocazione che apre la vulnerabilità. Si tratta di misure con effetti collaterali reali, dato che togliere il limite di memoria espone il server a esaurire la RAM per colpa di uno script difettoso, e per questo vanno considerate un ponte di poche ore e non una soluzione.

Chi ha Imunify360 dispone di una protezione aggiuntiva a livello di WAF. CloudLinux ha pubblicato tre aggiornamenti successivi delle regole, descritti nel suo blog: la 8.83 blocca la forma dell'exploit pubblico che passa per l'upload progress, ma su LiteSpeed si limita a registrarlo; la 8.84 blocca lo strumento pubblico tramite la sua firma anche su LiteSpeed; la 8.85 copre ulteriori varianti. Sui server cPanel con Apache la versione installata si legge così, e se è inferiore alla 8.85 si forza l'aggiornamento:

cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION
imunify360-agent update --force modsec-rules

Lo stesso blog avverte che nessuna regola blocca ancora il percorso di CVE-2026-109618 legato all'esaurimento della memoria e che la regola 8.84 può bloccare un modulo di caricamento legittimo ospitato su un altro dominio. Il WAF, in altre parole, compra tempo ma non sostituisce l'aggiornamento.

Come capire se qualcuno è già entrato

Aggiornare chiude la porta, ma non dice nulla su chi potrebbe essere entrato prima. Huntress indica che uno sfruttamento riuscito si manifesterebbe con ogni probabilità sotto forma di processi figli sospetti avviati da PHP, e suggerisce di cercare in particolare:

• processi php-fpm, php-cgi, httpd o apache2 che lanciano una shell come sh o bash, un interprete come python o perl, oppure strumenti di rete come curl, wget o nc;
• righe di comando con le forme tipiche delle reverse shell, come /dev/tcp/, fsockopen o mkfifo;
• comandi di ricognizione eseguiti dall'utente del web server, come whoami, id o uname -a.

Se emerge qualcosa di sospetto, Huntress raccomanda di isolare il server, conservare i log del web server e di PHP e cercare webshell, file nuovi nella cartella dei siti, cron job e account creati di recente. È anche il momento in cui un piano di risposta agli incidenti scritto prima, a mente fredda, fa la differenza fra una giornata difficile e una settimana persa.

In sintesi

PHP2Shell è una coppia di vulnerabilità critiche che permette l'esecuzione di codice senza autenticazione e che riguarda tutte le modalità con cui PHP serve pagine web, con mod_php nella posizione più esposta. Le versioni ufficiali corrette sono la 8.5.12, la 8.4.27, la 8.3.36 e la 8.2.35. Su cPanel, CloudLinux e Plesk le correzioni sono già disponibili anche per diversi rami a fine vita, ma spesso con lo stesso numero di versione di prima, e per questo la verifica va fatta sul changelog o sulla data di compilazione del pacchetto e non con php -v. Ogni versione installata va aggiornata, ogni processo PHP va riavviato, e le mitigazioni sul php.ini o sul WAF vanno trattate come un rimedio di poche ore in attesa della patch.

Se preferite che ce ne occupiamo noi

Sappiamo che una vulnerabilità come questa arriva sempre nel momento meno comodo, e che su un server con dieci versioni di PHP e cento siti la parte difficile non è lanciare il comando, ma essere sicuri che ogni sito sia davvero coperto e che nessuno abbia smesso di funzionare dopo l'aggiornamento. Se gestite un server cPanel, Plesk o CloudLinux e volete che lo mettiamo in sicurezza noi, facciamo l'inventario di tutte le versioni installate, applichiamo gli aggiornamenti, verifichiamo pacchetto per pacchetto che la correzione sia presente e controlliamo gli indicatori di compromissione, consegnandovi alla fine un report di quello che abbiamo trovato e fatto.

Per un intervento singolo potete usare i nostri pacchetti ore senza scadenza, mentre se preferite non dover più rincorrere le patch, il supporto cPanel e il supporto Plesk includono gli aggiornamenti di sicurezza programmati di PHP, del sistema operativo e del pannello.

Scrivici oppure chiama lo 051 021 7656.

Fonti

1. PHP, Security advisory: CVE-2026-109618 and CVE-2026-109619, 21 ottobre 2026, descrizione delle vulnerabilità, versioni corrette, backport e mitigazioni.
2. PHP, Annuncio della release di sicurezza, 20 ottobre 2026, data e ora di pubblicazione delle correzioni.
3. CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP, meccanismo tecnico, versioni colpite e raccomandazioni.
4. Rapid7, CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP, percorsi di sfruttamento ed esposizione di mod_php e PHP-FPM.
5. Huntress, Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities, ricostruzione del leak e indicatori da cercare.
6. watchTowr, PHP Remote Code Execution FAQ: CVE-2026-109618, osservazione di tentativi di sfruttamento dal 21 ottobre.
7. Palo Alto Networks Unit 42, Threat Brief: Critical Vulnerabilities in PHP, stima delle istanze esposte.
8. cPanel, EasyApache 4 Change Log, versione 25.91 del 21 ottobre 2026 con i pacchetti ea-php corretti.
9. CloudLinux, PHP CVE-2026-109618 and CVE-2026-109619, stato di alt-php, ea-php e PHP nativo, comandi e regole Imunify360.
10. Plesk, Vulnerability CVE-2026-109618 and CVE-2026-109619: Remote code execution in PHP shipped with Plesk, versioni colpite e corrette di PHP per Linux e Windows e del componente sw-engine.
11. MassiveGRID, How to Patch PHP for CVE-2026-109618 and CVE-2026-109619, comandi di aggiornamento per Plesk.

Leggi anche il nostro confronto fra Plesk e cPanel e la guida su cosa sono le vulnerabilità zero day e come ci si difende.