Notizia5 min di lettura
PHP2Shell: le due falle di PHP già sfruttate e cosa aggiornare
Il 21 ottobre 2026 PHP ha rilasciato in emergenza le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per chiudere PHP2Shell, due falle che permettono di eseguire codice da remoto. Gli attacchi sono già in corso: chi ha un sito in PHP deve verificare la versione installata e aggiornarla.

Il 21 ottobre 2026 il team di PHP ha pubblicato in emergenza le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per correggere due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, chiamate insieme PHP2Shell. Permettono a chiunque, senza credenziali, di eseguire codice sul server. Secondo watchTowr i primi attacchi sono arrivati lo stesso giorno, e il 26 ottobre BleepingComputer ha riportato il primo caso confermato di esecuzione di codice riuscita. In Italia il CERT-AGID ha diramato l'allerta il giorno stesso.
Cosa sono le falle PHP2Shell, in parole semplici?
PHP è il linguaggio con cui funzionano WordPress, WooCommerce, PrestaShop, Joomla, Drupal e moltissimi gestionali sviluppati su misura. BleepingComputer ricorda che, secondo W3Techs, lo usa circa il 70% dei siti web.
Le due falle stanno nel motore di PHP, non in un plugin o in un tema. La prima sfrutta un errore nella gestione della memoria quando questa si esaurisce, la seconda uno stato interno che resta "sporco" fra una richiesta e l'altra. Il risultato è lo stesso: una richiesta costruita apposta può far eseguire comandi sul server che ospita il sito.
Per questo non basta avere WordPress e i plugin aggiornati. Se la versione di PHP sotto il sito è vecchia, il sito resta esposto anche con tutto il resto in ordine.
Quali versioni di PHP sono a rischio?
Secondo la scheda di watchTowr, basata sull'avviso ufficiale di PHP:
- PHP 8.2, 8.3, 8.4 e 8.5: sono vulnerabili le versioni precedenti rispettivamente a 8.2.35, 8.3.36, 8.4.27 e 8.5.12;
- PHP 7.4, 8.0 e 8.1: non esiste una versione ufficiale corretta, perché sono rami non più supportati; servono le patch della distribuzione Linux o del fornitore che offre il supporto esteso, oppure il passaggio a un ramo supportato;
- PHP 7.3 e precedenti, compreso PHP 5: nessuna correzione, si può solo aggiornare.
Sono coinvolti tutti i modi in cui PHP risponde alle richieste web (PHP-FPM, il modulo di Apache, php-cgi, LiteSpeed, FrankenPHP). Il rischio più alto riguarda Apache con il modulo PHP, la configurazione tipica di molti hosting condivisi.
Gli attacchi sono reali o solo teorici?
Sono reali. I dettagli tecnici sono trapelati online il 20 ottobre, prima della data concordata per la divulgazione, e diversi gruppi di ricerca hanno visto tentativi già nei giorni precedenti la patch. BleepingComputer riporta il caso documentato da un ricercatore di Perplexity: esecuzione di codice confermata su una trappola (honeypot) con Apache e PHP 8.4.26. L'autore stesso precisa che la configurazione era volutamente favorevole all'attaccante, quindi non dice quanto l'attacco funzioni ovunque.
Secondo watchTowr, il 26 ottobre l'agenzia americana CISA ha inserito CVE-2026-109618 nel catalogo delle vulnerabilità sfruttate. Il CERT-AGID, dal canto suo, il 25 ottobre ha contato 650 indirizzi potenzialmente vulnerabili fra quelli delle pubbliche amministrazioni italiane, e nei giorni successivi ha pubblicato strumenti per verificare l'esposizione.
C'è poi una terza falla, CVE-2026-115560, ancora senza correzione al 26 ottobre. Secondo PHP è sfruttabile solo con una combinazione insolita di configurazione e codice; in attesa della patch, l'indicazione è impostare session.upload_progress.enabled=0.
Cosa cambia per una piccola impresa?
Se il sito aziendale, il negozio online o l'area clienti girano su PHP, la domanda da farsi è semplice: chi aggiorna PHP sul server?
- Hosting condiviso: di solito PHP lo aggiorna il fornitore, ma spesso sei tu a scegliere la versione dal pannello. Se hai lasciato una versione vecchia "perché il sito funziona", è il momento di cambiarla.
- Server o VPS tuoi: l'aggiornamento spetta a te o a chi te lo gestisce.
- Gestionali installati anni fa: sono i casi più delicati, perché spesso girano su rami di PHP fuori supporto e non si possono aggiornare senza ritoccare il codice.
Cosa fare adesso?
- Controlla la versione di PHP dal pannello dell'hosting o chiedendola al fornitore. Deve essere almeno 8.2.35, 8.3.36, 8.4.27 o 8.5.12.
- Aggiorna e riavvia i processi PHP. watchTowr sottolinea che la correzione ha effetto solo dopo il riavvio dei processi: aggiornare il pacchetto e lasciarli girare non basta.
- Se sei su PHP 8.1 o più vecchio, pianifica il passaggio a una versione supportata dopo aver verificato la compatibilità di temi, plugin e codice su misura. Nel frattempo, se puoi, limita l'accesso da internet ai sistemi che non riesci ad aggiornare.
- Disattiva l'upload progress (
session.upload_progress.enabled=0) finché non arriva la patch per la terza falla. - Guarda i registri del server degli ultimi giorni e, se trovi file PHP che non riconosci, segui la procedura per un sito compromesso prima di rimettere tutto in linea.
Nello stesso mese anche alcuni plugin di WordPress sono finiti sotto attacco: ne ho scritto a proposito di Bricksforge.
Ne parliamo?
Quando seguo la manutenzione e l'hosting di un sito, che sia una vetrina o un negozio online, la versione di PHP è una delle prime cose che controllo, insieme a CMS e plugin. Se hai un gestionale o un'applicazione in PHP rimasta indietro di qualche versione, posso valutare con te la modernizzazione del software senza rifarlo da zero. Scrivimi dalla pagina contatti: ti dico in poco tempo se il tuo sito è esposto e cosa serve per metterlo al sicuro.
Fonti
- PHP2Shell security flaws now successfully exploited in the wild (BleepingComputer)
- CVE-2026-109618: Exploited Remote Code Execution in PHP (watchTowr)
- Due vulnerabilità critiche in PHP consentono l'esecuzione di codice da remoto (CERT-AGID)
- PHP2Shell: 650 URL potenzialmente vulnerabili tra gli indirizzi censiti in IPA (CERT-AGID)
Crediti delle immagini
- Copertina: foto di Pixabay su Pexels


