Vulnerabilità critica di PHP php2shell: cosa fare ora

Secondo l'annuncio ufficiale di PHP del 21 ottobre 2026, le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 correggono due falle critiche che possono consentire l'esecuzione remota di codice senza autenticazione. Entrambe hanno ottenuto 9,2 sulla scala CVSS v4.0, un punteggio standard di quanto una falla sia considerata pericolosa. Esecuzione remota di codice significa che un aggressore può eseguire comandi sul server con i privilegi dell'account del processo web.

È interessata ogni installazione PHP che risponde a richieste web: PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed. Amazon Threat Intelligence ha scritto il 21 ottobre che la sua rete di honeypot ha visto il primo tentativo di sfruttamento il 17 ottobre, quattro giorni prima della divulgazione. SecurityWeek riferisce che, secondo watchTowr, le prove di concetto in circolazione non hanno ancora raggiunto l'esecuzione di codice. I tentativi ci sono, la prova di un successo è limitata, e questo non è un motivo per aspettare.

Se il suo sito usa PHP, lo consideri interessato. Secondo l'agenzia Anadolu, l'FBI stima che PHP sia usato su circa il 70% dei siti web, e secondo la CISA può essere incorporato in altri software senza che lei lo veda. Il nostro strumento di rilevamento delle tecnologie dà dall'esterno una prima idea di ciò su cui gira il suo sito, ma non si aspetti che confermi la versione.

Per la versione esatta segua il percorso indicato da WordPress.org: nell'amministrazione di WordPress apra Strumenti, Salute del sito, Info, Server. Anche i pannelli di hosting di solito la mostrano, e per i siti non WordPress devono indicarla il suo sviluppatore o il suo provider. Se è inferiore al numero della sua serie (8.2.35, 8.3.36, 8.4.27 o 8.5.12), secondo gli avvisi di sicurezza di GitHub lei è interessato.

Su un hosting condiviso il server lo gestisce il provider, perciò il suo compito è chiedere per iscritto: PHP è stato aggiornato per queste falle e su quale versione mi trovo? Secondo WordPress.org, la posizione dei provider cambiava di ora in ora: alcuni avevano corretto, altri dicevano di essere protetti da un WAF, altri ancora ci lavoravano. Un WAF è un firewall che filtra le richieste in arrivo. Se la risposta è «siete protetti», chieda su quale versione è stato portato.

Secondo le note di rilascio di cPanel, EasyApache 4 25.91 corregge entrambe le falle da ea-php74 a ea-php85, mentre 25.92 ricompila i pacchetti ea-php74, ea-php80 e ea-php81. Questi pacchetti di solito arrivano con l'aggiornamento automatico, ma è una nostra lettura; l'amministratore del server deve verificare le versioni in WHM. Con Plesk vale la stessa domanda: chieda al suo provider il nome del pacchetto e il numero di versione. Se ha un server proprio, la knowledge base di Laravel Forge indica che gli aggiornamenti di sicurezza automatici non correggono PHP; va aggiornato a parte su ogni server. Il progetto PHP precisa inoltre che le distribuzioni Linux hanno ricevuto la correzione in anticipo e consiglia di «controllare i pacchetti del proprio fornitore».

PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP. Il suo team di sicurezza ha fornito correzioni minime del codice sorgente per 7.4, 8.0 e 8.1, e alcune distribuzioni le riportano a loro volta, ma potrebbero non essere arrivate nel pacchetto del suo hosting. WordPress.org ricorda inoltre che PHP precedente alla 8.2 non riceve aggiornamenti di sicurezza. Secondo VulnCheck sono stati contati più di 2,6 milioni di server PHP esposti a internet, almeno 1 milione dei quali con versioni a fine vita.

La CISA raccomanda di mettere offline i sistemi che non possono essere aggiornati o che usano 8.1 o precedenti. WordPress.org, citando l'NCSC britannico, consiglia di mettere offline il server fino all'aggiornamento se lo gestisce lei. Se il suo sito non genera guadagni, per esempio una semplice pagina vetrina, è un'opzione realistica. PHP 8.2 arriva a fine vita il 31 dicembre 2026; passare alla 8.2.35 le dà quindi solo un breve respiro, perciò pianifichi fin d'ora il suo percorso di versioni.

L'annuncio di PHP è chiaro: solo l'aggiornamento è una soluzione completa; le misure temporanee riducono l'esposizione a specifici percorsi di attacco ma non rendono sicura un'installazione. Anche l'avviso di GitHub indica il passaggio alla versione corretta come unica misura completa. La seconda falla richiede che due richieste arrivino allo stesso processo; più processi e il loro riciclo abbassano il tasso di successo senza eliminare il rischio, e nessuna configurazione lo elimina del tutto. La CISA suggerisce un WAF in via temporanea, e la parola temporanea qui conta.

Queste sono le misure elencate dall'annuncio di PHP, e deve applicarle l'amministratore del suo server, non lei. L'annuncio cita anche la correzione degli errori fatali e dei timeout che l'aggressore può provocare, e la rimozione delle impostazioni INI non valide o obsolete applicate a ogni richiesta. Secondo Codeable, WordPress non usa session.upload_progress; chieda comunque delle altre applicazioni presenti sul server.

• memory_limit=-1, impostato in modo che l'applicazione non possa sovrascriverlo (tramite php_admin_value)
• Un post_max_size basso: 8M senza caricamento di file, 32M con caricamenti, con upload_max_filesize al di sotto
• session.upload_progress.enabled=0 e riavvio di tutti i processi, impostato in php.ini o nella configurazione del pool, non tramite ini_set o .user.ini
• fatal_error_backtraces=0 su PHP 8.5
• Non usare RLIMIT_AS e RLIMIT_DATA, perché possono innescare la falla

Amazon Threat Intelligence dice che l'indagine dovrebbe partire almeno dal 17 ottobre, il giorno in cui è stato visto il primo tentativo. I suoi indicatori sono richieste POST verso caricamenti di moduli che contengono la stringa PHP_SESSION_UPLOAD_PROGRESS, voci sospette nei log del server web e attività di processi o modifiche ai file inattese. Chieda al suo provider o amministratore di cercarli. La CISA raccomanda inoltre di monitorare i processi PHP che aprono una shell o scaricano strumenti. Il nostro strumento di audit della sicurezza controlla le impostazioni di base visibili dall'esterno; non sostituisce i log e i file del server.

Il secondo tema sono i processi di lunga durata. Secondo la knowledge base di Laravel Forge, un aggiornamento riavvia PHP-FPM, ma i worker di coda, Horizon e Octane avviati da riga di comando continuano a girare con il vecchio PHP finché non vengono riavviati. Per verificare, esegua sul server php8.4 -v e php-fpm8.4 -v (se usa la 8.4); secondo Qualys, la versione restituita da php -v può differire dall'installazione che risponde alle richieste web. Se ha impostato memory_limit=-1 come ripiego, ripristini un valore finito. Se trova tracce o non può esserne certo, discuta con il suo amministratore del cambio delle password del database, delle chiavi API e delle password di amministrazione; è un principio generale di igiene, non qualcosa che le fonti affermino.

Si distinguono tre errori. Evitarli conta per la maggior parte delle aziende quanto l'aggiornamento stesso.

Amazon scrive che una finestra di patch di 7 o 30 giorni presuppone un ritardo che non esiste più; si deve misurare in ore. La PHP Foundation, dal canto suo, ha spiegato che la correzione era in preparazione da agosto, che il 20 ottobre gli identificativi CVE sono trapelati con informazioni errate e che il rilascio è stato anticipato di un giorno. La lezione è semplice: metta per iscritto di chi è il software sotto il suo sito, chi lo aggiorna e chi chiamare, e leghi a un calendario le versioni a fine vita.

• Pensare che basti aggiornare un plugin, un tema o WordPress: secondo WordPress.org, per questi problemi non serve né è previsto alcun aggiornamento di WordPress, e aggiornare un plugin o un tema non la protegge
• Fidarsi di php -v: la versione da riga di comando può differire dall'installazione che risponde alle richieste web
• Trattare un WAF come la soluzione: la CISA lo considera temporaneo, e un provider che dice di usarne uno non dimostra che la versione sia aggiornata