php2shell: le due vulnerabilità critiche di PHP e cosa fare sul tuo piano hosting

Il 21 ottobre 2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che in rete hanno preso il nome di "php2shell". Chi le sfrutta può far eseguire comandi al server senza conoscere nessuna password.

Ti spieghiamo cosa sono, quanto sono gravi e cosa puoi fare sul tuo piano hosting. Le informazioni sono aggiornate al 21 ottobre alle 20:52, ora italiana.

Cosa sono le due vulnerabilità

Il nome "php2shell" non è ufficiale: il progetto PHP usa solo i codici CVE, come ricorda il blog di AlmaLinux.

La prima, CVE-2026-109618, riguarda la memoria. Ogni richiesta PHP ha un limite di memoria. Con un modulo o un upload costruito apposta, un attaccante può farla esaurire (in gergo si parla di OOM, out of memory). In quel momento PHP interrompe la richiesta in modo brusco e lascia alcuni dati a metà. La pulizia finale li tratta come validi e la memoria si corrompe.

La seconda, CVE-2026-109619, nasce dal fatto che un processo PHP serve molte richieste una dopo l'altra. Se una richiesta si interrompe per un errore grave, alcune informazioni restano attive anche se la memoria che le conteneva è già stata liberata. La richiesta successiva le riusa. È quello che si chiama use-after-free: PHP usa un pezzo di memoria che aveva già restituito.

In entrambi i casi l'attaccante può eseguire codice sul server da remoto, senza autenticarsi, con i permessi dell'utente che esegue PHP.

Le falle sono state segnalate l'11 agosto da Calif e da OpenAI, in modo indipendente. Wiz e OpenAI hanno poi trovato altri modi per sfruttarle, come racconta la PHP Foundation. Secondo Fastly, il percorso di attacco più vecchio dimostrato esiste dal 2012.

Il rischio più alto riguarda Apache con PHP caricato come modulo (mod_php): lì l'attacco funziona prima ancora che parta il codice del sito. Con PHP-FPM e LiteSpeed è più difficile e spesso dipende da come è scritta l'applicazione, ma non è escluso.

Quali versioni sono colpite

Sono colpite tutte le versioni precedenti a 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Queste quattro sono le versioni corrette, insieme alla 8.6.0 RC4, ancora in prova. Al momento in cui scriviamo, su php.net non c'è nessuna 8.5.13 o 8.4.28.

PHP 8.1 e le versioni più vecchie non ricevono più aggiornamenti dal progetto PHP. Vista la gravità, il team di sicurezza ha pubblicato correzioni minime per 7.4, 8.0 e 8.1, ma solo come codice sorgente. Tocca a chi prepara i pacchetti integrarle.

cPanel ha già pubblicato i pacchetti EasyApache corretti (ea-php), dalla 7.4 alla 8.5. Per le versioni PHP di CloudLinux, quelle che scegli da "Seleziona versione PHP", la situazione è diversa. CloudLinux ha annunciato correzioni per tutte le versioni dalla 5.2 alla 8.5. Sulla sua pagina di stato risultano già disponibili la 7.4 e la 8.0 per diversi sistemi, e la 8.1 solo per Alpine Linux. Le versioni 8.2, 8.3, 8.4 e 8.5 corrette non risultano ancora pubblicate.

Quanto sono gravi

Per il progetto PHP entrambe valgono 9.2 su 10 nella scala CVSS 4.0, cioè "critica". La PHP Foundation lo aveva anticipato su X la sera prima. Red Hat le valuta 8.1 su 10 con la scala CVSS 3.1 e le classifica "Important", un gradino sotto (scheda Red Hat). Il punteggio 10.0 circolato prima dell'annuncio ufficiale era sbagliato, come ha chiarito la PHP Foundation.

In Italia il CSIRT dell'Agenzia per la Cybersicurezza Nazionale ha pubblicato un avviso, rilanciato anche su X, che invita ad aggiornare e a controllare eventuali compromissioni.

Ci sono già attacchi?

Le fonti non dicono tutte la stessa cosa. watchTowr vede tentativi di attacco su entrambe le falle, ma finora nessuno risulta andato a segno. Fastly parla di attacchi visti già prima dell'annuncio. Il CTO di Cloudflare ha scritto su X di aver visto i primi attacchi la mattina del 21 ottobre.

La CISA, l'agenzia statunitense per la sicurezza informatica, chiede di aggiornare subito. Allo stesso tempo scrive di non aver osservato sfruttamenti al momento della pubblicazione, e le due CVE non sono nel suo catalogo delle vulnerabilità sfruttate. Al momento in cui scriviamo non risultano compromissioni confermate.

Circolano anche programmi dimostrativi pubblici, non verificati, e alcuni potrebbero contenere malware. Non scaricarli e non provarli sul tuo sito.

Cosa non è ancora chiaro

Su X si parla di una patch 8.5.12 "incompleta". Tutto parte dalla segnalazione di un crash, ma chi l'ha rilanciata ha precisato che un crash da solo non prova un attacco riuscito. Per ora non è dimostrato e il team PHP non ha fatto dichiarazioni.

C'è poi un problema separato, che non è una falla di sicurezza dimostrata. Nelle versioni 8.4.27 e 8.5.12, i siti che usano SimpleXML possono andare in crash con l'errore "zend_mm_heap corrupted" (issue #24488). La correzione è in lavorazione. Se vedi questo errore dopo un aggiornamento, è probabile che si tratti di questo e non di un attacco.

Infine Fastly e altri ricercatori si aspettano varianti dello stesso problema. È probabile che servano altri aggiornamenti di PHP.

Cosa puoi fare sul tuo piano hosting

Scegli una versione PHP supportata

Sui nostri piani hosting scegli la versione PHP da cPanel, nella sezione "Seleziona versione PHP" di CloudLinux. Trovi le versioni dalla 7.4 alla 8.4. Se il tuo sito usa ancora 7.4, 8.0 o 8.1, passa alla 8.2 o a una versione più recente appena puoi: sono le versioni ancora seguite dal progetto PHP. La CISA arriva a consigliare di mettere offline i sistemi esposti con PHP 8.1 o precedente che non si possono aggiornare.

Prima del cambio controlla che tema e plugin siano compatibili con la nuova versione. Dopo il cambio apri le pagine principali del sito e prova i moduli di contatto. Se qualcosa non funziona, scrivici prima di tornare a una versione vecchia.

Controlla la tua versione di php

La versione impostata in cPanel e quella che il sito usa davvero non sempre coincidono. Per saperlo con certezza, crea nella cartella del sito un file chiamato per esempio info.php, scrivi dentro <?php phpinfo(); e aprilo dal browser. In alto trovi la versione. Prendi nota del numero e cancella subito il file, perché mostra a chiunque molti dettagli del server.

Se usi il terminale, ricorda che php -v mostra la versione della riga di comando, che può essere diversa da quella del sito.

Tieni d'occhio i segnali di allarme

Nei file e nei log del sito, questi sono i segnali da non ignorare:

• file PHP che non hai caricato tu, oppure file modificati senza motivo;
• operazioni pianificate (cron job) o account che non riconosci;
• nel log degli errori, messaggi "Allowed memory size ... exhausted" con l'indicazione "Unknown on line 0", cioè PHP che finisce la memoria prima di eseguire qualsiasi pagina.

Se trovi qualcosa, non cancellare nulla e scrivici: i log servono a capire cosa è successo. Tieni presente che un log pulito non garantisce che il sito sia al sicuro. Datadog ha riprodotto le due falle e ha visto che l'attacco può riuscire senza far andare in crash PHP, quindi senza lasciare errori evidenti nei log.

Aggiorna WordPress, temi e plugin

Tieni aggiornati WordPress, il tema e i plugin, e togli quelli che non usi. Questo non chiude le due falle, che sono dentro PHP, ma riduce gli altri modi in cui un sito può essere attaccato.

Se hai dubbi

Se non sai quale versione PHP usa il tuo sito, o temi che il cambio di versione rompa qualcosa, scrivici. Indicaci il dominio e la versione che vedi in cPanel, così possiamo risponderti più in fretta.