Il 21 ottobre 2026 il progetto PHP ha pubblicato un aggiornamento di sicurezza urgente per due vulnerabilità critiche, ribattezzate PHP2Shell, che permettono di eseguire codice su un server da remoto e senza credenziali. Pochi giorni dopo le falle risultavano già sfruttate in attacchi reali. PHP è il linguaggio su cui girano WordPress, Joomla, molti e-commerce e tanti gestionali web: se l'impresa ha un sito, con buona probabilità la questione la riguarda.

Cosa è successo

Le due vulnerabilità sono identificate come CVE-2026-109618 e CVE-2026-109619, entrambe con un punteggio di gravità di 9,2 su 10. I dettagli sono circolati il 20 ottobre, prima della data concordata per la correzione, e il giorno dopo sono uscite le versioni corrette. Quello che serve sapere:

  • Il rischio. Una richiesta web costruita ad arte, senza bisogno di accedere al sito, può portare all'esecuzione di codice sul server. I ricercatori hanno dimostrato anche la lettura della memoria dei processi PHP, dove possono trovarsi password e chiavi di accesso.
  • Chi è più esposto. Secondo il progetto PHP il rischio è più alto con Apache e mod_php, la configurazione di molti hosting condivisi. Sono coinvolte anche PHP-FPM, LiteSpeed e altre modalità di esecuzione.
  • Le versioni corrette. PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le distribuzioni Linux possono aver applicato la correzione mantenendo un numero di versione più vecchio: in quel caso fa fede l'avviso del fornitore.
  • Le soluzioni temporanee. Il progetto PHP indica alcune impostazioni che riducono l'esposizione, ma lo dice chiaramente: non esistono mitigazioni complete, aggiornare è l'unica scelta sicura.

Il 23 ottobre è stata segnalata una terza falla, CVE-2026-115560, che può portare all'esecuzione di codice solo in configurazioni particolari. Finché non arriva la correzione, si neutralizza disattivando l'opzione session.upload_progress.enabled.

Perché riguarda anche le PMI italiane

Il 25 ottobre l'Agenzia per la Cybersicurezza Nazionale, attraverso il CSIRT Italia, ha diffuso un'allerta con i numeri del nostro Paese. Su 741.523 servizi PHP rilevati in Italia, 285.149 usano versioni potenzialmente vulnerabili: l'81,9% di quelli di cui è stato possibile identificare la versione. Negli Stati Uniti la CISA ha inserito entrambe le falle nel catalogo delle vulnerabilità sfruttate attivamente.

Il dato più preoccupante però non riguarda queste falle, ma le versioni. Secondo un'analisi di Qualys su oltre 156 milioni di installazioni PHP, il 71% gira su versioni non più supportate. Per una PMI il caso tipico è il sito fatto qualche anno fa, che funziona e quindi nessuno tocca, su un hosting che nessuno controlla da tempo.

Tre domande da fare oggi a chi gestisce il sito

Che versione di PHP usa il nostro sito, e su quale hosting? La correzione del 21 ottobre è già stata applicata, e da quando? Il CMS, il tema e i plugin sono aggiornati e compatibili con una versione di PHP ancora supportata? Se nessuno sa rispondere, il primo problema è proprio questo.

Le versioni di PHP e le loro scadenze

Ogni versione di PHP riceve due anni di correzioni complete e poi due anni di sole correzioni di sicurezza. Dopo, nessun aggiornamento: se esce una falla come PHP2Shell, resta aperta. La situazione oggi, secondo il calendario ufficiale:

  • PHP 8.1 e precedenti. Fuori supporto. Per PHP2Shell il progetto ha pubblicato solo correzioni minime per 7.4, 8.0 e 8.1, da applicare a mano: non è una base su cui restare.
  • PHP 8.2. Riceve correzioni di sicurezza fino al 31 dicembre 2026, poi più nulla. Chi è su questa versione ha due mesi per pianificare il passaggio.
  • PHP 8.3. Correzioni di sicurezza fino al 31 dicembre 2027.
  • PHP 8.4. Supporto completo fino al 31 dicembre 2026, sicurezza fino al 31 dicembre 2028.
  • PHP 8.5. Supporto completo fino al 31 dicembre 2027, sicurezza fino al 31 dicembre 2029. La versione successiva, PHP 8.6, è attesa per il 19 novembre 2026.

Per WordPress, il CMS più diffuso, il minimo tecnico è PHP 7.4, ma la versione raccomandata è la 8.3 o superiore. In pratica, oggi un sito aziendale dovrebbe stare su PHP 8.3, 8.4 o 8.5, aggiornato all'ultima correzione.

Cosa fare in pratica

Il lavoro non è complicato, ma va fatto in ordine, perché cambiare versione di PHP a un sito vecchio senza preparazione può bloccarlo:

  • Verificare la versione. Si vede nel pannello dell'hosting o, su WordPress, in Strumenti › Salute del sito › Info › Server.
  • Applicare la correzione. Se il sito è su 8.2, 8.3, 8.4 o 8.5, chiedere all'hosting conferma scritta che la versione sia almeno quella corretta del 21 ottobre, o che la patch del fornitore sia stata installata.
  • Pianificare il passaggio di versione. Se il sito è su 8.2 o precedenti, passare a 8.4 o 8.5 entro dicembre: prima un backup completo, poi una prova su una copia del sito, infine il passaggio sul sito vero.
  • Aggiornare il resto. CMS, tema e plugin vanno aggiornati insieme a PHP: sono spesso loro a impedire il passaggio a una versione recente.
  • Controllare i segnali di attacco. L'ACN raccomanda di verificare nei log richieste anomale, errori di memoria esaurita e interruzioni improvvise dei processi PHP. Se compaiono, va coinvolto un tecnico prima di qualsiasi altra modifica.

Lo stesso controllo vale per gestionali, portali clienti e intranet scritti in PHP: spesso sono proprio quelli che nessuno aggiorna. Per le imprese che rientrano nella NIS2, la gestione delle vulnerabilità e degli aggiornamenti è una delle misure di sicurezza richieste, e il Cyber Index PMI conferma che è uno dei punti deboli più comuni.

Il punto

PHP2Shell non è la prima falla grave in PHP e non sarà l'ultima. La differenza la fa avere un sito su una versione supportata e qualcuno che applica le correzioni nei giorni in cui escono, non nei mesi successivi. Per molte PMI questa è l'occasione per sapere finalmente su cosa gira il proprio sito, e per sistemarlo prima del 31 dicembre, quando PHP 8.2 smetterà di ricevere aggiornamenti.

Approfondimenti. Per la sicurezza di siti, server e postazioni: vedi Voucher Cloud & Cybersecurity, che può finanziare parte degli interventi. Per gli obblighi delle imprese soggette alla direttiva: Adeguamento NIS2.

Questo articolo ha finalità divulgative e non costituisce consulenza tecnica o legale. Le informazioni provengono dall'avviso di sicurezza del progetto PHP (21 ottobre 2026) e dal calendario delle versioni supportate, dall'allerta dell'ACN ripresa da AGI (25 ottobre 2026), dall'analisi di Qualys, da BleepingComputer sul catalogo CISA e dalle note di WordPress sulle versioni di PHP. Versioni e scadenze vanno verificate sulle fonti ufficiali e con il proprio fornitore di hosting.

Testo redatto con l'ausilio di sistemi di intelligenza artificiale, a partire dalle fonti citate. La responsabilità editoriale dei contenuti è di Audacis S.r.l. Maggiori informazioni.