La vulnerabilità PHP del 21 ottobre: cosa deve fare chi ha un PrestaShop

Il 21 ottobre 2026 il progetto PHP ha corretto due vulnerabilità critiche che toccano ogni PrestaShop: permettono a chiunque, senza login, di eseguire codice sul server che risponde alla richiesta. Non riguardano un modulo o una versione di PrestaShop: riguardano il PHP che c’è sotto, quindi toccano ogni negozio, dal più aggiornato al più vecchio. Il nome con cui girano, anche negli avvisi di Cloudflare e PrestaShop, è php2shell. Una vulnerabilità PHP, PrestaShop non la può correggere: la chiude solo chi aggiorna il PHP del server.

Questo pezzo non è la traduzione del bollettino. Qualche ora dopo il rilascio ho controllato i due shop PrestaShop che seguo su hosting condiviso, e quello che ho trovato è il motivo per cui scrivo: nessuno dei due era ancora protetto, e il numero di versione da solo non lo diceva. Due giorni dopo ho rifatto il giro, e cosa è cambiato il 23 ottobre ha qualche sorpresa in più.

⚠️ Cosa è successo, in breve

Il PHP Security Team ha mandato un preavviso il 20 ottobre e ha pubblicato le correzioni il 21 alle 14:00 UTC (le 16:00 in Italia), come da annuncio ufficiale su php.net. Le due falle hanno un punteggio CVSS 9.2 ciascuna:

• CVE-2026-109618 (advisory GHSA-w8hw-w9fx-j79w): quando la memoria si esaurisce, PHP può fermarsi con i dati della richiesta inizializzati a metà, e la pulizia successiva li tratta come validi.
• CVE-2026-109619 (advisory GHSA-6wmf-4rv5-p3rp): lo stato interno di una richiesta sopravvive alla memoria già liberata, e la richiesta successiva servita dallo stesso processo può usarlo.

Tradotto per chi vende online: un attaccante remoto può mandare in crash PHP, leggere dati che non dovrebbe vedere o eseguire codice sul server. Sono colpite tutte le installazioni che servono pagine web: PHP-FPM, Apache con mod_php (il caso peggiore, con un exploit dimostrato che parte prima che venga eseguita una sola riga di PrestaShop), php-cgi, FrankenPHP e LiteSpeed.

Le versioni corrette sono queste:

PrestaShop ha pubblicato lo stesso giorno un avviso per i merchant che dice in sostanza le stesse cose. Il problema è che quasi nessun titolare di un e-commerce gestisce il PHP del proprio server: lo gestisce l’hosting. Ed è lì che le cose si complicano.

🛠️ Cosa ho trovato sui due shop che seguo

Alle 21:50 del 21 ottobre, cioè quasi sei ore dopo il rilascio, ho letto la situazione su due PrestaShop in produzione che gestisco, entrambi su hosting condiviso con CloudLinux e LiteSpeed, un tipo di hosting molto diffuso fra le PMI italiane. Solo lettura, nessuna modifica.

Tre cose escono da questa tabella, e nessuna sta nei bollettini.

Il numero di versione non basta, guarda la data. Su CloudLinux il PHP che usi viene da pacchetti alt-php mantenuti dal fornitore del sistema, che continua a correggerli anche quando il progetto PHP li ha abbandonati. Il PHP 7.3.33 di uno shop è nato anni fa, ma il suo binario è stato ricompilato a febbraio 2026: lo stesso numero può essere vulnerabile o corretto. Qui la data di febbraio dice che la correzione di ottobre non c’è ancora. Il rovescio vale per tutti: il giorno in cui l’hosting aggiorna, il numero potrebbe restare uguale. Fa fede la conferma scritta del fornitore, non il numero.

Le versioni vecchie arrivano per ultime. Alle 19:00 UTC CloudLinux scriveva che i pacchetti corretti erano disponibili per PHP 7.4 e 8.0 sulla maggior parte delle piattaforme, per l’8.1 solo su alcune, mentre 7.0-7.3 e 8.2-8.5 erano ancora in test. Lo shop B, su PHP 7.3, sta nel gruppo che aspetta. Ed è anche fuori dai requisiti ufficiali: secondo i requisiti di PrestaShop 1.7, la 1.7.4 arriva al massimo a PHP 7.1.

Il firewall dell’hosting, su LiteSpeed, guarda e basta. Il ruleset di Imunify360 uscito per queste falle ha una regola che blocca lo schema di attacco pubblico, ma su LiteSpeed quella regola non viene eseguita: resta solo quella che registra senza bloccare. È scritto nella stessa pagina di CloudLinux. Se il tuo hosting ti dice “abbiamo il WAF”, su un server LiteSpeed oggi questo vuol dire meno di quanto sembra.

Lo shop più aggiornato e quello più vecchio avevano lo stesso problema.
Su questa falla la versione di PrestaShop non conta, conta chi aggiorna il PHP e quando.

🛠️ Aggiornamento del 23 ottobre: cosa è cambiato in due giorni

Ho rifatto la verifica la mattina del 23 ottobre, sempre in sola lettura, sui due shop e sugli altri siti che gestisco: tre server in tutto, più un vecchio VPS di cui parlo sotto.

Il numero è rimasto uguale, come previsto. Fra le 21:52 del 21 ottobre e le 00:24 del 22 tutti i binari PHP sono stati ricompilati, dalla 7.0 alla 8.5, e nessuno ha cambiato numero: 8.1.34 resta 8.1.34, 7.3.33 resta 7.3.33, e la 8.4 è ancora 8.4.26, uno sotto la 8.4.27 ufficiale. CloudLinux ha confermato di aver portato la correzione su tutti i rami di alt-php, anche quelli abbandonati (per esempio alt-php81 dalla release 8.1.34-39), pubblicati nei repository stabili la notte fra il 21 e il 22. Chi avesse controllato solo il numero nel back office avrebbe concluso di essere ancora scoperto.

Il supporto dell’hosting ha detto un’altra cosa. Alla stessa domanda il supporto tecnico ha risposto per iscritto che il fix c’era solo dalla 8.2 in su, che per 8.1, 8.0 e 7.4 non erano previste patch, e ha consigliato di salire almeno alla 8.2. Il fornitore del sistema dice che la patch c’è, l’hosting che lo installa dice di no, e da un account condiviso la release del pacchetto non si legge (rpm non è disponibile). Se ti capita, chiedi la release esatta del pacchetto, non la versione di PHP: per esempio l’output di rpm -q alt-php81, da confrontare con la tabella di CloudLinux. Qualche ora dopo lo stesso hosting ha mandato a tutti i clienti una comunicazione ufficiale che rimette le cose a posto: sull’hosting condiviso i pacchetti alt-php sono stati aggiornati con il backport di sicurezza e i servizi PHP riavviati, ed è normale che phpinfo() mostri ancora il numero vecchio. La risposta del ticket era fuorviante, la circolare no: quando le due cose non coincidono, fa fede quella scritta da chi gestisce l’infrastruttura, non dall’operatore di turno.

Lo shop A l’ho portato su PHP 8.2. Quando ho deciso, la circolare non era ancora arrivata: con due risposte scritte in contrasto, la scelta più solida era la versione che entrambi davano per corretta. Col senno di poi la 8.1 era già protetta, ma la 8.2 resta un passo avanti: è ancora supportata dal progetto PHP fino a fine anno. È fuori dai requisiti ufficiali di PrestaShop 8, e qui sotto spiego perché in questo caso specifico era una scelta ragionevole e non un salto al buio:

• lo shop era già rimasto un giorno intero su PHP 8.2 ad agosto, per un errore nel pannello, senza un solo errore nei log;
• prima del cambio ho salvato estensioni e opzioni della 8.1 e le ho ricopiate identiche sulla 8.2, che aveva estensioni diverse rimaste dal tentativo precedente;
• display_errors spento: su PHP 8.2 PrestaShop 8 genera avvisi di deprecazione che non devono finire a video;
• home, categoria e scheda prodotto controllate saltando la cache di LiteSpeed, cioè generate davvero dal PHP nuovo, poi carrello e contatti: nessun errore;
• i cron dello shop girano con un PHP da riga di comando separato, quindi il cambio non li tocca;
• tornare indietro è un comando, con la configurazione della 8.1 rimasta intatta.

Su un altro PrestaShop 8, mai provato su 8.2 e con moduli che non conosci, quel ragionamento non vale: resta il percorso in staging descritto sotto.

Lo shop B non ha scelta. Un PrestaShop 1.7.4 non sale oltre PHP 7.3 senza rompersi, quindi resta affidato al backport di CloudLinux, che l’hosting ha confermato installato, e alla virtual patch di Imunify360 che l’hosting dichiara attiva a livello di infrastruttura. È il caso in cui la migrazione smette di essere un progetto rimandabile.

Il caso peggiore era un server che nessuno guardava più. Accanto ai due shop c’era un vecchio VPS con Plesk su Debian 10, rimasto acceso dopo una migrazione: ospitava la copia del vecchio negozio, un PrestaShop su PHP 7.1, un sito di test e un paio di siti ancora attivi. Debian 10 e quella versione di Plesk non ricevono più aggiornamenti: lì la patch non arriverà mai, per nessun ramo PHP. In mezz’ora ho spento session.upload_progress nella configurazione di ogni versione di PHP del server, sospeso la copia del vecchio shop e il sito di test, e sostituito il PrestaShop su PHP 7.1 con una pagina statica. Attenzione a quest’ultimo passaggio: se spegni PHP lasciando la cartella dello shop come radice del sito, il server comincia a servire i file .php come testo, compreso quello con le credenziali del database. La pagina statica va in una cartella nuova, e quella vecchia esce dal web. I siti rimasti si spostano su un hosting aggiornato: il tampone copre una sola delle due falle.

Se dopo una migrazione hai lasciato acceso il vecchio server “per sicurezza”, controllalo oggi: è il posto dove una falla come questa resta aperta per sempre.

✅ Come verifichi la versione PHP del tuo shop in cinque minuti

Non serve accesso SSH. Serve il back office e una mail.

1. Leggi la versione. Nel back office di PrestaShop vai in Parametri avanzati > Informazioni: la versione di PHP sta nella sezione del server. Annotala insieme alla versione di PrestaShop.
2. Confrontala con la tabella sopra. Se è 8.2.35, 8.3.36, 8.4.27 o 8.5.12 o successive, il PHP è una versione corretta. Se è più bassa, non vuol dire per forza che sei scoperto (vedi il punto sulle date), ma vuol dire che devi chiedere.
3. Scrivi all’hosting, non telefonare. La risposta deve restare scritta. Una richiesta che funziona è questa:

Buongiorno, sul mio account [dominio] gira PHP [versione].
Mi confermate per iscritto che la correzione per CVE-2026-109618
e CVE-2026-109619 (PHP, 21/10/2026) è installata per questa versione
e che i processi PHP del mio sito sono stati riavviati dopo
l'aggiornamento? Se per la mia versione la patch non c'è ancora,
mi indicate quando arriva e se potete disattivare
session.upload_progress.enabled nella configurazione PHP del mio account?

4. Ricontrolla dopo la risposta. Un pacchetto installato ma non caricato non protegge: i processi PHP già in memoria continuano a girare con il codice vecchio finché non vengono riavviati. Per questo nella mail il riavvio è chiesto in modo esplicito.

⚠️ Il caso più delicato: PrestaShop 1.7 e 8, fermi su PHP fuori supporto

Qui c’è il dettaglio che nei bollettini non si legge. Le versioni corrette partono da PHP 8.2, ma nessun PrestaShop 1.7 o 8 può usarle: la 1.7.8, l’ultima della serie, arriva al massimo a PHP 7.4, e secondo i requisiti di PrestaShop 8 tutta la serie 8, fino alla 8.2, si ferma a PHP 8.1. Cioè proprio le versioni per cui il progetto PHP non pubblica release, ma solo un backport del codice sorgente pensato per chi compila da sé. Lo shop A della tabella è un PrestaShop 8.2 aggiornato e tenuto bene, e sta su PHP 8.1 perché più in alto non può andare.

Su un hosting condiviso la protezione di questi shop dipende quindi da una sola cosa, se il fornitore del sistema ricompila la tua versione vecchia. CloudLinux lo ha fatto per tutti i rami, dalla 7.0 alla 8.1, entro la notte fra il 21 e il 22 ottobre; altri fornitori, o un vecchio server fuori supporto, possono non farlo mai. Solo PrestaShop 9, che parte da PHP 8.1 e con la 9.1 arriva alla 8.5, può girare su un PHP corretto dal progetto stesso.

La tentazione, la sera stessa, è alzare la versione di PHP dal pannello dell’hosting. Non farlo al buio: un PrestaShop 8 su PHP 8.2 è fuori dai requisiti, un 1.7 su PHP 8 non gira, e anche fra versioni vicine un tema o un modulo vecchio possono rompere il checkout senza che te ne accorga subito. Su uno dei due shop l’ho fatto, ma con una prova già alle spalle e le verifiche descritte nell’aggiornamento del 23 ottobre. Il percorso corretto è a gradini e in staging, ed è lo stesso che ho descritto in come aggiornare PrestaShop dalla 1.7 alla 8: prima la 8 sul PHP vecchio, poi il PHP, poi la 9.

Un aggiornamento major non è un’emergenza da fare stanotte, e lo dice anche l’avviso di PrestaShop. Quello che va fatto stanotte è chiedere la patch per la versione che hai. La migrazione si pianifica, ma va pianificata adesso: come, lo trovi più sotto. E chi è già su PrestaShop 9 con PHP 8.2 ha una scadenza sua: il supporto di PHP 8.2 finisce il 31 dicembre 2026, come indica la tabella delle versioni supportate, quindi il salto a 8.3 o superiore va messo in calendario entro fine anno.

🛠️ Le mitigazioni temporanee (solo con un tecnico)

Se l’aggiornamento non può arrivare subito, il progetto PHP indica alcune misure che riducono l’esposizione ma non rendono sicura l’installazione. Le riporto per completezza, con le avvertenze che contano su un PrestaShop:

• session.upload_progress.enabled = 0 contro CVE-2026-109619, impostato nel php.ini, nel pool FPM o nella configurazione del server, poi riavvio dei processi. Non da .user.ini né con ini_set(): si applicano troppo tardi e non servono. Nel codice di PrestaShop 8.2 non c’è un solo riferimento a upload_progress, quindi sullo shop non si perde niente; se accanto allo shop girano altre applicazioni PHP, vanno controllate a parte. Su PrestaShop conviene lasciarlo spento anche dopo la patch.
• Su PHP 8.5 anche fatal_error_backtraces = 0 a livello server, sempre contro CVE-2026-109619, poi riavvio dei processi.
• Limiti bassi alla dimensione delle richieste contro CVE-2026-109618 (post_max_size a 8M senza upload, 32M con upload). Su PrestaShop attenzione: import CSV del catalogo, caricamento di immagini e installazione di moduli da zip usano richieste grandi. Si prova in staging, non in produzione.
• memory_limit = -1 è una misura avanzata che ha senso solo con un limite di memoria esterno, a livello di container: da sola apre un problema diverso.
• Nascondere gli errori non aiuta. display_errors spento o la chiocciola davanti alle funzioni non cambiano niente.

Se hai Cloudflare davanti allo shop, ha attivato regole dedicate dalle 03:02 UTC del 21 ottobre su tutti i piani con il WAF, Free compreso; sui piani a pagamento va verificato che il ruleset gestito sia in modalità blocco. Servono solo se il server accetta traffico esclusivamente da Cloudflare: se l’IP del server risponde anche direttamente, un attaccante passa di lato.

✅ Fino a PHP 8.5 si arriva: è un lavoro, non una tendina

Il PHP più recente, la 8.5, su un PrestaShop si può avere. Non spostando la versione nel pannello dell’hosting: su uno shop 8 o 1.7 quella mossa può far saltare il sito: errori fatali del core, moduli che non caricano, un checkout che smette di funzionare. Ci si arriva con PrestaShop 9.1, che regge PHP fino alla 8.5, la versione che i requisiti ufficiali di PrestaShop 9 consigliano.

Il percorso è sempre lo stesso, ed è il lavoro che faccio:

1. copia completa dello shop in staging, file e database, mai sul negozio che vende;
2. inventario di tema e moduli, uno per uno, con la versione compatibile o il sostituto quando il modulo è abbandonato;
3. aggiornamento a gradini del core e del PHP, con un test del checkout, dei pagamenti e delle spedizioni a ogni gradino;
4. passaggio in produzione con il backup verificato e un piano per tornare indietro già pronto.

Fatto così, alla fine hai uno shop su un PHP che riceve le correzioni direttamente dal progetto PHP, invece di aspettare che qualcuno ricompili per te una versione abbandonata, come succede oggi a chiunque sia su PrestaShop 1.7 o 8. La prossima falla PHP, che prima o poi arriva, la chiudi con un aggiornamento di routine invece che con una serata di mail all’hosting.

✅ Cosa resta da fare nei prossimi giorni

L’emergenza di oggi si chiude con la patch. Quello che resta è più noioso e più utile: sapere sempre che PHP gira sotto il tuo shop, e chi lo aggiorna. È la voce “PHP supportato” della mia checklist di sicurezza PrestaShop, e questa settimana ha smesso di essere teoria.

La verifica rifatta sui due shop è nell’aggiornamento del 23 ottobre. Se il tuo negozio non ha nessuno che segue queste cose, fa parte del lavoro di assistenza PrestaShop che faccio sugli shop in produzione. Scrivimi o usa uno dei canali qui sotto, con versione di PrestaShop, versione di PHP e nome dell’hosting.

Fonti: annunci PHP del 20 e 21 ottobre 2026, advisory CVE-2026-109618, advisory CVE-2026-109619, avviso PrestaShop ai merchant, stato dei pacchetti CloudLinux e ruleset Imunify360, pacchetti alt-php corretti e come verificarli, stato dei repository CloudLinux, regole WAF Cloudflare, requisiti PHP di PrestaShop 1.7, 8 e 9, versioni PHP supportate. I dati dei due shop vengono da letture fatte il 21 ottobre 2026 alle 21:50 e il 23 ottobre in mattinata su negozi e server che gestisco, riportati senza riferimenti ai clienti né all’hosting.