PHP2Shell, vulnerabilità critica di PHP: CVE-2026-109618 e CVE-2026-109619, corrette nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35
Sicurezza Informatica

Vulnerabilità PHP: cosa insegna PHP2Shell a chi ha un sito vetrina

Il 21 ottobre sono usciti gli aggiornamenti di emergenza per PHP2Shell, una doppia vulnerabilità PHP di gravità critica. PHP è il linguaggio con cui funziona la maggior parte dei siti internet, WordPress compreso, e la notizia era trapelata il giorno prima su un forum, costringendo gli sviluppatori ad anticipare i tempi.

Se il tuo sito è fatto con WordPress, Joomla, Drupal o un altro programma in PHP, la cosa ti riguarda anche se lo tieni aggiornato, perché il difetto sta nel motore che fa funzionare il programma, i plugin e i temi.

Che cosa è successo

Le due falle, CVE-2026-109618 e CVE-2026-109619, hanno un punteggio di gravità di 9,2 su 10. Permettono a chiunque, senza password, di eseguire comandi sul server mandando al sito richieste costruite ad arte, e in alcuni casi di leggere la memoria del server, dove passano le password del database e le chiavi dei servizi collegati. I ricercatori le hanno provate con successo su WordPress, Drupal e Joomla, e i primi tentativi di attacco sono stati segnalati poche ore dopo la pubblicazione.

In parole semplici, PHP sbaglia a fare pulizia in due situazioni: quando esaurisce la memoria mentre legge una richiesta, per esempio un modulo con un allegato, e quando passa da una visita alla successiva lasciando in memoria tracce della precedente. All’attaccante non serve trovare un punto debole nel sito, dato che in molte configurazioni gli basta che il sito risponda.

Che cosa fare subito

L’unico rimedio vero è aggiornare PHP alle versioni 8.5.12, 8.4.27, 8.3.36 o 8.2.35, mentre aggiornare WordPress non serve, perché il problema sta sotto. L’Agenzia per la Cybersicurezza Nazionale, nel bollettino del 21 ottobre, consiglia anzi di sospendere i siti che non si possono aggiornare subito.

Su un hosting condiviso l’aggiornamento tocca al fornitore, e conviene scrivergli per sapere se l’ha già installato, perché non tutti sono stati rapidi. Se invece il sito sta su un server tuo, o gestito da qualcuno per te, va aggiornato adesso, riavviando PHP. I siti fermi a PHP 8.1 o a versioni precedenti non riceveranno correzioni ufficiali e vanno portati a una versione supportata; del resto anche la 8.2 smetterà di riceverne a fine anno.

Quando l’aggiornamento è arrivato tardi, conviene far controllare il server: un attacco riuscito lascia tracce, e una password del database rubata resta valida finché qualcuno non la cambia.

Un sito vetrina non deve mostrare il motore

Gran parte dei siti aziendali sono vetrine, che presentano l’azienda, cambiano poche volte l’anno e vengono modificate da due o tre persone. Eppure a ogni visita mettono al lavoro PHP, e il loro pannello di amministrazione è raggiungibile da chiunque, in tutto il mondo.

Si può fare diversamente. Il sito si gestisce con WordPress come sempre, ma su un server che da internet non si vede, al quale si accede soltanto dagli indirizzi IP certificati dell’ufficio o tramite VPN. Al pubblico arrivano solo le pagine già pronte, consegnate da un reverse proxy, cioè un server che sta davanti al sito e risponde ai visitatori al suo posto. Chi visita il sito non nota alcuna differenza, mentre chi cerca il pannello di amministrazione, o un PHP da attaccare, non trova niente.

Con una falla come questa, a dover restare nascosto è PHP nel suo insieme. Limitare il solo pannello agli indirizzi dell’ufficio aiuta contro chi prova a indovinare le password, ma contro PHP2Shell non sarebbe bastato, perché il difetto si raggiunge da qualunque pagina pubblica. Il modulo di contatto, l’unica parte che deve ricevere dati dal pubblico, si può affidare a un piccolo servizio separato. In cambio le pagine si caricano più in fretta, e la prossima falla si affronta senza l’affanno di chi ha il motore in vetrina.

Quando il sito deve restare aperto

Il discorso cambia per i negozi online, i portali di prenotazione e le aree riservate ai clienti, dove il visitatore non si limita a leggere. Lì PHP deve rispondere a chiunque in tempo reale, e ci si protegge aggiornando subito, mettendo un firewall applicativo davanti al sito e tenendo il server separato dal resto della rete aziendale. Per tutti gli altri siti, pubblicare anche il retrobottega non ha senso, ed è una scelta che si fa una volta, quando si progetta o si rinnova il sito.

Dell’accesso riservato agli strumenti aziendali abbiamo parlato nell’articolo sulle nuove VPN aziendali; come costruiamo la sicurezza delle aziende che seguiamo è spiegato nella pagina sulla sicurezza informatica per le aziende.

Hai bisogno di una consulenza IT?

Il team Ejart è a tua disposizione per consulenze, supporto e soluzioni su misura.

Contattaci 📞 06 4341 2978
Torna in alto