Vulnerabilità PHP di ottobre 2026: cosa rischia un sito e cosa chiedere all'hosting

Esposte

• 8.2, 8.3, 8.4 e 8.5 non aggiornate
• 8.1 e precedenti: senza aggiornamenti ufficiali

Aggiornare WordPress, i plugin o il tema non cambia nulla.

→ aggiorna PHP

Corrette (21 ottobre 2026)

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Dopo l'aggiornamento PHP va riavviato.

Cosa è successo con PHP in questi giorni?

Il 21 ottobre 2026 il progetto PHP ha pubblicato un avviso di sicurezza urgente con due correzioni per falle che permettono l'esecuzione di codice da remoto senza autenticazione. PHP è il linguaggio su cui girano WordPress, molti gestionali web e una gran parte dei siti aziendali.

Le due falle hanno ricevuto gli identificativi CVE-2026-109618 e CVE-2026-109619. Una CVE è il numero di catalogo con cui si indica una vulnerabilità nota. Entrambe hanno punteggio 9,2 su 10 nella scala CVSS v4.0, che misura la gravità: siamo nella fascia critica.

Secondo la ricostruzione di watchTowr, i dettagli sono circolati sui social il 20 ottobre, prima della data di divulgazione prevista, e lo stesso 21 ottobre la società ha osservato tentativi di sfruttamento nella sua rete di sistemi esca. Rapid7, il 22 ottobre, scrive di non aver visto attacchi riusciti su larga scala, ma di aver ricevuto più segnalazioni di tentativi. Esistono già dimostrazioni pubbliche, ciascuna valida solo per una specifica combinazione di sistema operativo, versione di PHP e server web.

Che cosa permettono di fare queste falle?

Permettono a chi attacca di far eseguire al server un proprio programma, con gli stessi diritti con cui gira il sito. Da lì può leggere i file del sito, le password del database, modificare le pagine o installare software malevolo.

Il meccanismo è tecnico, ma si può immaginare così. PHP gestisce ogni richiesta del visitatore come una pratica da aprire, lavorare e chiudere, e alla chiusura ripulisce la scrivania.

• CVE-2026-109618: se a PHP finisce la memoria mentre sta ancora aprendo la pratica, si ferma a metà. La pulizia finale poi tratta come valido del materiale non preparato, e un attacco ben costruito può sfruttarlo. Secondo Rapid7 una richiesta con molti allegati (multipart) può esaurire la memoria anche rispettando i limiti impostati.
• CVE-2026-109619: un'informazione di una pratica già chiusa resta sulla scrivania e punta a memoria ormai liberata. La richiesta successiva, gestita dallo stesso processo, può usarla prima che venga azzerata.

Secondo l'avviso di PHP, il rischio più alto è con Apache in modalità mod_php, dove un attacco dimostrato riesce prima che giri qualsiasi codice del sito. Con PHP-FPM, la configurazione più diffusa sui server recenti, l'avviso e Rapid7 non riportano uno sfruttamento completo, ma il codice è comunque vulnerabile.

Chi è coinvolto, e il mio sito?

È coinvolta ogni installazione di PHP che risponde a richieste web: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed e FrankenPHP. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

Il punto più importante per chi ha un sito: il difetto è in PHP, non nel sito. Secondo Codeable, WordPress.org ha dichiarato che nessun aggiornamento di WordPress è richiesto né previsto. Aggiornare WordPress, i plugin o il tema non cambia nulla: serve aggiornare PHP sul server.

Cambia molto a seconda di dove sta il sito:

• Hosting condiviso o gestito: PHP è aggiornato dal fornitore per tutti i clienti insieme. SiteGround, per esempio, ha comunicato di aver applicato le correzioni a tutti i suoi server il 21 ottobre. Altri fornitori vanno verificati uno per uno.
• Server virtuale (VPS) o server dedicato: l'aggiornamento tocca a chi lo amministra, che può essere la tua web agency o un freelance. Se nessuno lo fa, resta tutto com'è.
• Sito su una versione vecchia di PHP: PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto. Per 7.4, 8.0 e 8.1 PHP ha pubblicato correzioni minime del codice sorgente, e alcune distribuzioni Linux ne offrono versioni adattate. Per 7.3 e precedenti non esiste nessuna correzione. Inoltre PHP 8.2 termina il supporto il 31 dicembre 2026.

Cosa dire a chi gestisce il mio hosting?

Chiedi cose precise e fatti verificabili, non rassicurazioni generiche. Se il tuo sito lo gestisce un'agenzia o un freelance, queste domande valgono per loro; se è un hosting condiviso, vanno al supporto del fornitore.

1. Hai applicato la correzione del 21 ottobre 2026 al server dove sta il mio sito? Quando, e da quale pacchetto o versione?
2. Quale versione di PHP usa il mio sito? Il numero visibile può ingannare: le distribuzioni Linux spesso correggono il codice senza cambiare il numero, quindi chiedi se la correzione è inclusa nel pacchetto.
3. PHP è stato riavviato dopo l'aggiornamento? Un processo già in esecuzione continua a usare il vecchio codice finché non viene riavviato.
4. Se uso PHP 8.1 o precedente, qual è il piano? Passare a 8.3 o 8.4 con un periodo di prova, oppure un pacchetto con correzione adattata da un fornitore.
5. Ci sono filtri davanti al sito? Un servizio come Cloudflare può bloccare parte degli attacchi, ma Codeable avverte che non sostituisce l'aggiornamento: chi attacca può raggiungere il server anche senza passare dal filtro.
6. Puoi controllare i log degli ultimi giorni per segni di intrusione? Rapid7 precisa che l'assenza di errori nei log non dimostra che il sito sia stato al sicuro.
7. Chi ci avvisa, e quando, la prossima volta? Meglio concordare un tempo massimo per le correzioni critiche, per esempio pochi giorni.

Cosa fare subito, e se non si può aggiornare?

La risposta di PHP è netta: l'aggiornamento è l'unico rimedio completo, e nessuna impostazione rende sicura un'installazione. Le misure temporanee riducono solo l'esposizione.

Per un sito su hosting condiviso:

1. Controlla la pagina di stato o la comunicazione del fornitore e, se non trovi nulla, scrivi al supporto con le domande sopra.
2. Se il pannello di controllo ti permette di scegliere la versione di PHP e usi la 8.1 o una precedente, pianifica il passaggio a una versione supportata. Prima fai un backup e prova il sito.
3. Non cambiare impostazioni del server da solo: sono ambiti del fornitore.

Per chi amministra un server:

1. Installa il pacchetto aggiornato e riavvia tutti i processi PHP.
2. Finché non è possibile, l'avviso di PHP elenca misure temporanee: disattivare session.upload_progress.enabled nella configurazione del server (non con ini_set() né .user.ini, che intervengono troppo tardi) e, con PHP 8.5, disattivare fatal_error_backtraces. Servono poi limiti più bassi sulla dimensione delle richieste, per esempio post_max_size a 8M se il sito non riceve file.
3. Dove un server non si può aggiornare subito, limita l'accesso da Internet. Codeable riporta che WordPress.org e il centro di sicurezza britannico NCSC suggeriscono, per i server gestiti da soli, anche di mettere il sito offline.

session.upload_progress.enabled = 0

Domande frequenti

Se il mio sito è già stato violato, me ne accorgo?

Non necessariamente. Secondo Rapid7 la mancanza di voci nei log non prova che un sito sia stato al sicuro. Se il tuo fornitore non ha corretto il server prima del 21 ottobre, chiedi un controllo dei file modificati di recente e dei nuovi utenti amministratori.

Basta un firewall o un servizio come Cloudflare?

No. Codeable riferisce che Cloudflare ha attivato regole di protezione su tutti i piani, e può essere utile come strato in più. Ma l'avviso di PHP indica l'aggiornamento come unica soluzione completa, e un server raggiungibile direttamente resta esposto.

Il mio sito è su PHP 8.2: sono a posto?

Solo se la versione è la 8.2.35 o successiva, oppure se il fornitore conferma una correzione equivalente. Tieni presente che PHP 8.2 termina il supporto il 31 dicembre 2026, quindi conviene programmare il passaggio a una versione più recente.

Devo aggiornare WordPress o i plugin?

Per queste falle no: sono in PHP. Gli aggiornamenti di WordPress e dei plugin restano comunque buona norma, ma non risolvono questo problema.

Fonti

• PHP.net: Security advisory, critical remote code execution vulnerabilities, update now (21 ottobre 2026)
• Rapid7: CVE-2026-109618 and CVE-2026-109619, Critical Unauthenticated Remote Code Execution in PHP
• watchTowr: PHP2Shell FAQ, CVE-2026-109618 & CVE-2026-109619 Fixes
• Codeable: PHP Security Release on 21 October 2026, what WordPress site owners need to do
• SiteGround: critical PHP vulnerabilities, October 2026

Ti serve una mano in azienda?

Mi occupo di consulenza IT e AI per piccole aziende e professionisti, in Puglia e da remoto.

Servizi

Approfondimento scritto con l'assistenza dell'AI a partire dalle fonti indicate e controllato da me prima della pubblicazione.