In una riga: il 21 ottobre 2026 PHP ha corretto due falle critiche, soprannominate “php2shell”, che permettono a chiunque di prendere il controllo di un sito senza nemmeno fare login. Riguardano quasi tutti i siti WordPress del mondo. Qui trovi cosa fare, passo per passo, che tu abbia un hosting normale o un server tuo, e come proteggerti se la correzione per il tuo sistema non è ancora arrivata.
Cos’è successo, in parole semplici
PHP è il linguaggio su cui girano WordPress, WooCommerce, PrestaShop, Joomla e buona parte dei siti che visiti ogni giorno. Il 20 ottobre i dettagli di due errori gravissimi (si chiamano CVE-2026-109618 e CVE-2026-109619) sono finiti in rete prima che esistesse la correzione. Il giorno dopo il progetto PHP ha pubblicato le versioni sistemate, e l’agenzia americana per la sicurezza informatica (CISA) e quella inglese (NCSC) hanno chiesto a tutti di aggiornare subito.
Il problema, detto senza tecnicismi: inviando al sito una richiesta costruita apposta, come quelle che partono quando compili un modulo o carichi un file, un malintenzionato può far eseguire al server i suoi comandi. Non serve una password, non serve un account. Le società di sicurezza che seguono la vicenda dicono che più gruppi stanno già riproducendo l’attacco e che un exploit pubblico è questione di giorni: è il momento in cui partono le scansioni automatiche di tutto internet.
Sei esposto? Controlla la versione di PHP
Le versioni sicure sono queste, o successive:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Le versioni 8.1, 8.0 e 7.4 sono fuori supporto: non riceveranno la correzione. Se il tuo sito usa una di queste, la soluzione è passare almeno a PHP 8.3.
Come la trovi in WordPress: Bacheca → Strumenti → Salute del sito → scheda Informazioni → sezione Server → “Versione PHP”. Oppure nel pannello del tuo hosting (cPanel, Plesk o simili), di solito alla voce “Versione PHP” o “Gestione PHP”.
Se hai un hosting condiviso (il caso più comune)
Qui il lavoro grosso spetta al provider, ed è una buona notizia: molti si sono mossi in anticipo, SiteGround ad esempio ha annunciato protezioni prima ancora dell’uscita della correzione. Quello che puoi fare tu:
- Controlla la versione come sopra. Se è già una di quelle sicure, sei a posto su questo fronte.
- Se è più vecchia, scrivi al supporto, anche con questo messaggio: “Buongiorno, il mio sito usa PHP [versione]. Avete già aggiornato ai rilasci del 21 ottobre che correggono CVE-2026-109618 e CVE-2026-109619? Se no, quando lo farete?”
- Se il pannello ti fa scegliere la versione e sei su 7.4, 8.0 o 8.1, passa a 8.3 o 8.4. Prima fai un backup, poi controlla che il sito si apra e che i plugin funzionino.
Se hai un server tuo (VPS, cloud, Docker)
Qui tocca a te. Il primo passo è aggiornare i pacchetti di PHP e riavviare i servizi:
- Debian e Ubuntu:
sudo apt update && sudo apt upgrade, poisudo systemctl restart php8.3-fpm(con il numero della tua versione) e Apache o Nginx. - Rocky, Alma, RHEL, Amazon Linux:
sudo dnf upgrade 'php*'esudo systemctl restart php-fpm. Su Amazon Linux 2023 le correzioni arrivano con le nuove “release”:sudo dnf --releasever=latest upgrade 'php*'. - Docker: scarica di nuovo l’immagine ufficiale (
php:8.3-fpm,wordpress:lateste simili) e ricrea il container. Unrestartnon basta: serve l’immagine nuova.
Dopo l’aggiornamento verifica con php -v. E ricorda che conta la versione usata dal sito (PHP-FPM o il modulo di Apache), non solo quella del terminale: la pagina “Salute del sito” di WordPress è il controllo più affidabile.
Cosa fare se la correzione per il tuo sistema non c’è ancora
Il progetto PHP ha pubblicato le versioni corrette il 21 ottobre, ma le distribuzioni Linux e i provider ci mettono da qualche ora a qualche giorno a renderle installabili. Nel frattempo non conviene restare scoperti. Queste sono le protezioni temporanee suggerite dagli esperti che hanno analizzato le falle, le stesse che uso anch’io quando una correzione tarda ad arrivare.
1. Blocca gli upload da internet, se il sito non ne ha bisogno. Il veicolo principale dell’attacco sono le richieste di tipo “multipart”, quelle dei moduli con allegati e del caricamento di file. Su un blog i visitatori non caricano niente: lo fa solo chi gestisce il sito dall’area di amministrazione. Se l’amministrazione la usi da un indirizzo fisso, o meglio da una VPN (ne ho parlato in come raggiungo casa e questo sito da ovunque con Tailscale), puoi bloccare quelle richieste per tutti gli altri. Con Apache basta un file di configurazione così:
LimitRequestBody 33554432
LimitRequestFields 60
<Location "/">
<If "req('Content-Type') =~ m#multipart/#i && ! -R 'IL.TUO.IP.FISSO'">
Require all denied
</If>
</Location>Con Nginx, dentro il blocco server:
set $multipart 0;
if ($http_content_type ~* "multipart/") { set $multipart 1; }
if ($remote_addr = "IL.TUO.IP.FISSO") { set $multipart 0; }
if ($multipart = 1) { return 403; }Attenzione: se il tuo sito ha moduli con allegati, un negozio WooCommerce con caricamento di file o un’area clienti, questo blocco li fermerebbe. In quel caso limita la regola alle pagine che non ne hanno bisogno, oppure affidati a un firewall applicativo (Cloudflare, il WAF del tuo hosting) e aggiorna il prima possibile.
2. Cambia alcune impostazioni di PHP-FPM, nel file del pool (per esempio /etc/php-fpm.d/www.conf o /etc/php/8.x/fpm/pool.d/www.conf), usando php_admin_ in modo che i plugin non possano modificarle:
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[fatal_error_backtraces] = 0
php_admin_value[post_max_size] = 32MGli analisti suggeriscono anche di togliere il limite di memoria (memory_limit = -1), perché una delle due falle scatta proprio quando una richiesta arriva al limite. È una scelta da valutare: senza limite una richiesta impazzita può consumare tutta la RAM e fermare il sito, quindi ha senso solo su server con memoria in abbondanza e per pochi giorni. Dopo ogni modifica va riavviato PHP-FPM.
3. Metti l’aggiornamento in automatico, o tieni d’occhio la distribuzione. Appena il pacchetto corretto è disponibile, installalo, riavvia PHP e controlla che il sito risponda. A quel punto le protezioni temporanee si possono togliere con calma.
Come capire se ti hanno già colpito
Se il tuo sito è rimasto scoperto da martedì 20 ottobre, fai questi controlli. Non sono una garanzia, ma prendono i casi più comuni:
- File PHP dove non dovrebbero esserci. La cartella
wp-content/uploadscontiene immagini e documenti, mai file.php. Da terminale:find wp-content/uploads -name "*.php". Se ne trovi, è un pessimo segno. - File modificati di recente:
find . -name "*.php" -mtime -3elenca i file PHP cambiati negli ultimi tre giorni. Se non hai aggiornato niente, non dovrebbe uscire nulla. - Utenti amministratori sconosciuti in Bacheca → Utenti.
- Nei log del server, una raffica di richieste POST di tipo multipart verso pagine qualsiasi, magari con errori 500.
- Una scansione con un plugin di sicurezza come Wordfence o con lo scanner del tuo hosting.
Se trovi qualcosa: non cancellare a caso. Fai una copia di tutto, cambia le password (WordPress, database, FTP e hosting), ripristina un backup pulito precedente al 20 ottobre e aggiorna PHP prima di rimettere online il sito.
La lista da fare oggi
- Controlla la versione di PHP del sito.
- Se non è tra quelle sicure, aggiorna, o chiedi al provider di farlo.
- Se l’aggiornamento non è disponibile, metti le protezioni temporanee.
- Fai i controlli per capire se qualcuno è già entrato.
- Già che ci sei, attiva la verifica in due passaggi sull’account dell’hosting e su WordPress: ne ho parlato in aggiornamenti, verifica in due passaggi e passkey.
Una falla così è il promemoria più efficace di una regola noiosa ma vera: un sito non si fa e si lascia lì. Va aggiornato, come il telefono.
