PHP2Shell: la vulnerabilità di PHP che mette a rischio il tuo PrestaShop

Il 20 ottobre è scattato un avviso che ha tenuto col fiato sospeso mezzo internet: due gravi vulnerabilità PHP, il linguaggio su cui gira il tuo negozio PrestaShop, che permettono a uno sconosciuto di prendere il controllo del server senza utente né password. Le chiamano PHP2Shell. PHP ha pubblicato la patch il 21 ottobre, e quello che devi fare dipende da una cosa sola: la versione di PHP su cui gira il tuo negozio.

Te lo spieghiamo senza tecnicismi: cosa è successo, come capire se ti riguarda, cosa fare oggi e come sapere se il tuo hosting ha già applicato la correzione.

Che cos'è PHP2Shell e perché è così grave?

PHP è il motore che sta sotto PrestaShop, WordPress, Magento e la maggior parte dei negozi e dei siti del mondo. Le due vulnerabilità, registrate come CVE-2026-109618 e CVE-2026-109619, hanno un punteggio di gravità di 9,2 su 10. In pratica, chi sa sfruttarle può eseguire quello che vuole sul tuo server: installare una backdoor, rubare i dati dei tuoi clienti o infilare nel tuo negozio un falso captcha come quello di ClickFix.

Quello che la rende diversa da altri avvisi è che l'attacco non passa né da PrestaShop né da un modulo. Avviene in PHP, prima ancora che il tuo negozio legga la visita. Non importa quanto sia curato: se il PHP del server è vulnerabile, lo è anche il negozio.

E le informazioni sono trapelate prima del tempo. La società di sicurezza Sansec racconta che insieme all'avviso è comparso lo screenshot di uno strumento d'attacco già pronto, e si aspettava attacchi di massa appena fosse uscita la patch. Secondo la stessa fonte, Cloudflare aveva già visto i primi tentativi e ha messo delle regole per bloccarli.

Il mio negozio PrestaShop è a rischio?

Molto probabilmente sì. Nel suo bollettino di sicurezza, PHP considera a rischio qualsiasi installazione che serva pagine web, in qualunque modo il server la esegua, e il rischio più alto sui server Apache con mod_php, dove esiste già un attacco dimostrato che funziona senza utente né password. Sansec parla di qualsiasi server con PHP 5.4 o successivo, cioè in pratica qualsiasi negozio PrestaShop attivo oggi.

La domanda che conta davvero è un'altra: ti arriva la correzione? PHP l'ha corretta nelle versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per le versioni vecchie, che non hanno più supporto ufficiale, PHP ha pubblicato la patch senza una nuova versione, e in uno o due giorni i pannelli e i sistemi usati dagli hosting l'hanno trasformata in un aggiornamento normale: cPanel e CloudLinux, da PHP 5.2 fino a 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux e il repository di Remi, nelle versioni dalla 7.4 alla 8.1 che mantengono ancora. E ogni versione di PrestaShop funziona solo con alcune versioni di PHP:

• PrestaShop 1.6: funziona con PHP 5.6–7.1. La patch c'è se il tuo hosting usa cPanel o CloudLinux; altrove, solo con un supporto esteso a pagamento, come quello di TuxCare o Zend.
• PrestaShop 1.7: al massimo PHP 7.4. Il 7.4 con la patch esiste già in quasi tutti i pannelli: manca solo che il tuo hosting lo installi.
• PrestaShop 8: al massimo PHP 8.1. Come per la 1.7: l'8.1 con la patch esiste già e dipende dal tuo hosting installarlo.
• PrestaShop 9: funziona con PHP 8.1–8.4. Con PHP 8.2 o superiore riceve l'aggiornamento ufficiale; se è su 8.1, basta aggiornare PHP.

In altre parole: quasi tutti i negozi oggi possono girare su un PHP senza questa falla. Ma se il tuo non è PrestaShop 9, dipende dal fatto che l'hosting abbia installato la patch, e siccome il numero di versione non cambia, non si vede a colpo d'occhio: bisogna chiederglielo. Ed è una patch d'emergenza: PHP 8.1 e precedenti non hanno supporto ufficiale, quindi alla prossima falla dipenderai di nuovo da qualcuno che la corregga per conto suo.

Come capire che versione hai

Entra nel back office del negozio e apri Parametri Avanzati → Informazioni. Lì vedi la versione di PrestaShop e, poco più sotto, quella di PHP. Con questi due numeri sai già in quale caso sei.

Cosa fare oggi, in ordine

1. Controlla le tue due versioni, PrestaShop e PHP, come ti abbiamo spiegato sopra.
2. Fai un backup completo, file e database, e conservalo fuori dal server. Se succede qualcosa, è l'unica cosa che ti permette di tornare indietro.
3. Se il tuo negozio è PrestaShop 9, chiedi al tuo hosting di aggiornare PHP alla 8.2.35, 8.3.36, 8.4.27 o 8.5.12 o successive, oppure fallo tu dal pannello dell'hosting se ti lascia scegliere la versione. Se sei su PHP 8.1, approfittane per passare a 8.3 o 8.4.
4. Se usi Cloudflare, verifica che la nuvola del tuo dominio sia arancione: così il traffico passa dalle sue regole prima di arrivare al tuo server. Serve a poco se l'indirizzo del tuo server è noto e accetta visite da chiunque, quindi chiedi al tuo tecnico di limitarlo al solo traffico di Cloudflare.
5. Se il tuo negozio è 1.6, 1.7 o 8, chiedi al tuo hosting se ha già installato la patch di PHP2Shell per la tua versione di PHP. Se non ce l'ha, chiedi al tuo tecnico le misure d'emergenza che spieghiamo più sotto. E fissa una data per l'aggiornamento a PrestaShop 9: è il modo per tornare a un PHP con supporto ufficiale.

Mettere il negozio in manutenzione dal back office stavolta non ti protegge: PHP legge la visita prima che PrestaShop decida di mostrare la pagina di manutenzione.

E se il mio hosting non ha la patch?

PHP propone alcune impostazioni del server che chiudono parte delle strade dell'attacco, e avverte che non rendono sicuro il negozio: solo l'aggiornamento lo fa. Sansec aggiunge un'altra misura d'emergenza: bloccare sul server il tipo di invio con cui viaggiano i file che si caricano su un sito. Ha un prezzo: finché resta attiva, nessuno può caricare file sul tuo negozio. Né tu le foto di un prodotto nuovo, né i tuoi clienti un allegato nel modulo di contatto. Il negozio continua a vendere normalmente.

Serve a guadagnare qualche giorno, non a restare così: o il tuo hosting installa la patch, o passi a uno che ce l'ha. E la prossima volta che esce una falla in PHP —e usciranno—, il tuo negozio dipenderà di nuovo da questo, perché PHP 8.1 e precedenti non hanno più supporto ufficiale.

Quale PHP supporta ogni versione di PrestaShop e fino a quando riceve le patch lo trovi in una tabella in quale versione PHP per PrestaShop.

Conviene aggiornare PrestaShop adesso?

È la domanda che si rimanda sempre perché il negozio funziona. PHP2Shell è quello che succede quando la si rimanda troppo: il giorno in cui arriva il problema non lo scegli tu, e che la correzione ti arrivi dipende da altri.

Passare a PrestaShop 9 ti mette su un PHP che riceve patch per anni. Si fa senza chiudere il negozio, ti porti dietro prodotti, clienti, ordini e posizioni su Google, e un negozio piccolo costa a partire da 690 €. Lo spieghiamo per intero in aggiornare PrestaShop 1.7 o 1.6 a 9, e nella nostra pagina sulla migrazione da PrestaShop 1.6 e 1.7 a 9.

E se preferisci non dover stare dietro a questi avvisi, a questo serve la manutenzione PrestaShop: sorvegliamo il tuo negozio, teniamo aggiornati i suoi moduli e, se è su un server BK Modules, anche PHP, così un avviso del genere non ti coglie impreparato.

Ti serve aiuto oggi?

Se non sai in quale caso sei, se il tuo hosting non ti risponde o se il tuo negozio è 1.6, 1.7 o 8 e vuoi uscirne, dicci la tua versione di PrestaShop e quella di PHP. Ti diciamo cosa fare oggi e, se serve, ti diamo un prezzo chiuso per passare a PrestaShop 9.

Voglio aggiornare il mio negozio

Per il tuo team tecnico

Versioni corrette: 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per 7.4, 8.0 e 8.1, PHP pubblica la correzione minima in codice sorgente, collegata dal suo avviso, senza una nuova versione. I pacchetti con la patch mantengono il numero di versione, quindi php -v non li distingue: bisogna guardare la revisione del pacchetto (rpm -q, dpkg -l). Revisioni corrette: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Le misure parziali indicate da PHP vanno nel php.ini, nel pool di PHP-FPM (php_admin_value) o nella configurazione del server, mai con ini_set() né .user.ini, riavviando tutti i processi:

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M se non si caricano file
; CVE-2026-109619
session.upload_progress.enabled = 0
; solo in PHP 8.5
fatal_error_backtraces = 0

PHP chiede di non sostituire memory_limit con limiti di sistema (RLIMIT_AS, RLIMIT_DATA). La misura di Sansec, bloccare multipart/form-data (blocca tutti i caricamenti di file, back office compreso), su Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Su Nginx:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Con Cloudflare, limitare la porta 443 dell'origine ai suoi intervalli di IP; altrimenti l'attacco arriva diretto all'IP del server.