Vulnerabilità ps_facetedsearch: l'aggiornamento PrestaShop da non rimandare

Punteggio 10 su 10, sfruttabile senza alcun account

Il 3 giugno 2026 il team di PrestaShop ha pubblicato una patch d'emergenza per ps_facetedsearch, il modulo di ricerca a faccette installato di serie sulla quasi totalità dei negozi dalla versione 1.7.1.0. La vulnerabilità ps_facetedsearch corretta ha il punteggio massimo della scala CVSS: 10.0.

Tre caratteristiche la rendono temibile:

• non richiede alcuna autenticazione: né un account cliente, né un accesso al back office;
• si sfrutta dal front office, con una semplice richiesta HTTP;
• porta all'esecuzione di codice da remoto, cioè al caricamento sul suo server di un file PHP pilotabile dall'esterno.

In pratica, un bot che scandaglia i negozi PrestaShop può prendere il controllo del suo senza che nulla compaia nella cronologia dell'amministrazione.

Come funziona la vulnerabilità

Il modulo tiene in cache i blocchi dei filtri per non ricalcolare le faccette a ogni visita. I valori dei filtri a cursore (prezzo, peso) vengono letti dall'URL e poi salvati in quella cache in forma serializzata.

Il problema nasce in rilettura. Fino alla versione 4.0.3 il modulo applicava a quei valori la funzione PHP nativa unserialize() senza una validazione preventiva sufficiente. Chi attacca può quindi costruire un URL che contiene un oggetto PHP malevolo. Alla deserializzazione, l'oggetto innesca una catena di gadget presente nelle dipendenze di PrestaShop e finisce per scrivere un file arbitrario nella cartella del modulo.

La patch ufficiale sostituisce unserialize() con \Tools::unSerialize(), il wrapper sicuro di PrestaShop.

Il suo negozio è esposto?

Versioni vulnerabili: dalla 3.0.0 alla 4.0.3. Versione corretta: 4.0.4.

Controlli la versione in Moduli > Gestore dei moduli, cercando ps_facetedsearch. In alternativa può leggere il tag <version> nel file modules/ps_facetedsearch/config.xml.

Sul database basta una query:

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

Sotto la 4.0.4 consideri il negozio esposto, anche se i filtri compaiono solo su qualche categoria: il controller resta comunque raggiungibile.

La correzione: due strade possibili

Aggiornare il core. Lo stesso giorno PrestaShop ha rilasciato le versioni 8.2.7 e 9.1.4, che includono il modulo corretto. È la strada consigliata se è già vicino a queste versioni.

Aggiornare solo il modulo. Scarichi ps_facetedsearch 4.0.4 dal repository ufficiale e sostituisca la cartella. È l'opzione più rapida quando un passaggio di versione del core comporta un vero progetto di collaudo.

In entrambi i casi, dopo l'intervento svuoti var/cache/prod/ e la cache del modulo. Se non può intervenire subito, applichi le mitigazioni pubblicate insieme al bollettino: togliere i filtri a cursore dai template pubblici, svuotare la cache della ricerca a faccette e bloccare sul web application firewall le richieste la cui query string contiene i marcatori tipici della serializzazione PHP (O:, ;i:).

Capire se il negozio è già stato visitato

Una patch non richiude una porta già usata. Dopo l'aggiornamento cerchi le tracce di un file caricato.

File PHP modificati di recente nei moduli:

find modules/ -name "*.php" -mtime -60 -ls

Pattern tipici di una backdoor:

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Controlli inoltre:

• la cartella modules/ps_facetedsearch/: qualsiasi file .php estraneo alla distribuzione ufficiale è sospetto;
• i log di accesso dell'hosting, alla ricerca di richieste con stringhe anomale per lunghezza;
• la tabella ps_employee: un account amministratore sconosciuto indica una compromissione pensata per durare;
• i file .htaccess e robots.txt, spesso modificati per nascondere pagine di spam.

Se trova qualcosa, non si limiti a cancellare il file. Un'intrusione porta quasi sempre con sé una seconda backdoor. Vanno cambiate tutte le password dei dipendenti, rigenerate le chiavi di config/settings.inc.php — _COOKIE_KEY_ compresa — e ripristinato un backup anteriore all'intrusione. Il nostro articolo su un negozio PrestaShop violato descrive la procedura completa.

La lezione: un modulo di serie non è un modulo sicuro

Molti commercianti tengono d'occhio i moduli di terze parti e lasciano vivere di vita propria quelli nativi. Questo episodio ricorda che il codice distribuito di serie gira su centinaia di migliaia di negozi: è proprio quello che interessa di più a chi attacca.

Tre abitudini riducono il rischio in modo netto:

• seguire i bollettini di sicurezza di PrestaShop e di Friends-of-Presta;
• applicare le patch di sicurezza entro 72 ore, passando da un ambiente di staging quando il negozio è complesso;
• tenere un inventario delle versioni dei moduli, per rispondere in cinque minuti alla domanda «sono coinvolto?».

È esattamente ciò che copre un contratto di manutenzione PrestaShop.

Serve un audit subito?

Verifichiamo la sua versione, applichiamo la patch e cerchiamo le tracce di un'intrusione. Diagnosi gratuita, risposta entro 1 ora, dalle 9 alle 22, 7 giorni su 7.