Aggiornamento sicurezza ps_facetedsearch: cosa devono fare gli ecommerce PrestaShop

Il progetto PrestaShop ha pubblicato il 3 giugno 2026 un advisory di sicurezza critico per il modulo Faceted Search (ps_facetedsearch), identificato come GHSA-m5f5-28qr-9g9r. Il punteggio CVSS è 10.0 su 10: il livello massimo possibile. Se il tuo negozio usa un filtro a cursore per prezzo o peso, è esposto a esecuzione remota di codice senza alcuna autenticazione. Non è un aggiornamento da rimandare.

Cosa comunica l'advisory GHSA-m5f5-28qr-9g9r

La vulnerabilità è classificata come PHP Object Injection. Il modulo ps_facetedsearch ricostruisce i filtri di ricerca attivi a partire dai parametri URL. Il valore di un filtro a cursore — prezzo o peso — viene letto dall'URL senza una validazione sufficiente, poi salvato in una cache interna attraverso serializzazione PHP nativa. Quando quella cache viene riletta, il valore viene deserializzato con unserialize() senza alcuna protezione.

Un attaccante può costruire un valore appositamente formato da inserire nel parametro URL del cursore. Quel valore diventa un oggetto PHP malevolo all'interno della cache. Durante la deserializzazione, una catena di gadget scrive un file PHP arbitrario nella directory del modulo, che viene poi usato come webshell per eseguire comandi sul server.

L'attacco è remoto, non autenticato e richiede una singola richiesta HTTP al front office. Una volta sfruttato, l'attaccante ha il pieno controllo del negozio e del server sottostante.

Versioni interessate e patch

Il problema tecnico: unserialize() non protetto

Il punto critico è nel file src/Filters/Block.php, nel metodo getFromCache(). Il codice originale usa la funzione PHP nativa unserialize() su dati che provengono, anche indirettamente, dall'input dell'utente. La versione corretta sostituisce questa chiamata con \Tools::unSerialize(), il wrapper sicuro fornito da PrestaShop che include controlli sulle classi deserializzabili.

La modifica da applicare manualmente, se non è possibile aggiornare subito il modulo:

[code=language-php]// Prima (vulnerabile)

if (!empty($row)) {

return unserialize(current($row));

}

// Dopo (sicuro)

if (!empty($row)) {

return \Tools::unSerialize(current($row));

}[/code]

Questa correzione va applicata in modules/ps_facetedsearch/src/Filters/Block.php. Il metodo da modificare si chiama getFromCache().

Azioni immediate se non puoi aggiornare subito

L'advisory ufficiale indica tre misure da adottare nell'attesa dell'aggiornamento:

1. Rimuovi i filtri a cursore (prezzo e peso) dai template di filtro esposti nel front office. Senza un cursore attivo, il percorso di attacco non è raggiungibile.
2. Svuota la cache dei filtri a faccette e controlla la directory modules/ps_facetedsearch/ alla ricerca di file PHP inattesi. Se trovi file con nomi casuali o non riconoscibili, il sistema potrebbe essere già compromesso.
3. Monitora i log delle richieste e blocca a livello WAF o di server le richieste che contengono pattern di serializzazione PHP nei parametri URL.

Per il punto tre, i pattern da cercare nei log sono stringhe che iniziano con O: (oggetto serializzato), sequenze ;i:, o riferimenti a classi note come Monolog\. Un esempio di pattern da bloccare con una regola nginx o in un modulo WAF:

[code=language-bash]# Esempio di regola di monitoraggio nei log nginx

# Cerca parametri URL con pattern di serializzazione PHP

grep -E "(\?|&)[^=]+=O%3A|%3Bi%3A|Monolog" /var/log/nginx/access.log

# Alternativa con stringa decodificata (se i log non sono URL-encoded)

grep -E "(\?|&)[^=]+=O:[0-9]+:" /var/log/nginx/access.log[/code]

Come verificare la versione installata

Dal Back Office PrestaShop, vai su Moduli → Gestore moduli e cerca "Faceted Search". La versione è visibile direttamente nella scheda del modulo. In alternativa puoi verificarla da riga di comando:

[code=language-bash]grep -i "version" modules/ps_facetedsearch/config.xml | head -5[/code]

Se la versione è compresa tra 3.0.0 e 4.0.3, il sistema è vulnerabile e l'aggiornamento è urgente.

Perché ps_facetedsearch è un componente critico

La ricerca a faccette è una delle funzioni più esposte al pubblico in un ecommerce: riceve parametri URL da chiunque navighi il sito, inclusi bot, crawler e sistemi automatizzati. Proprio per questo motivo è un bersaglio attraente. La vulnerabilità GHSA-m5f5-28qr-9g9r dimostra che anche componenti considerati "di catalogo" possono nascondere rischi di esecuzione di codice remoto se il codice che elabora l'input non è sufficientemente difensivo.

In condizioni normali, la ricerca a faccette migliora l'esperienza di acquisto e aiuta il cliente a trovare più rapidamente il prodotto. Il problema nasce quando richieste automatizzate o costruite ad arte sfruttano la logica interna del modulo per raggiungere funzioni che non dovrebbero essere accessibili dall'esterno.

Controlli immediati da fare sul tuo ecommerce

1. Verifica la versione del modulo

Accedi al Back Office e controlla la versione installata di Faceted Search. Confrontala con le informazioni dell'advisory GHSA-m5f5-28qr-9g9r: se è tra 3.0.0 e 4.0.3, pianifica l'aggiornamento immediato alla 4.0.4.

2. Controlla la directory del modulo

Verifica la presenza di file PHP non riconoscibili nella directory del modulo. Un comando rapido da SSH:

[code=language-bash]find modules/ps_facetedsearch/ -name "*.php" -newer modules/ps_facetedsearch/ps_facetedsearch.php

# Elenca i file PHP modificati dopo il file principale del modulo

# File inattesi qui sono un segnale di compromissione[/code]

3. Esegui un backup prima dell'intervento

Prima di aggiornare un modulo che incide su catalogo e navigazione, esegui sempre un backup completo del database e dei file. È una misura prudente, soprattutto per ecommerce con personalizzazioni, override, temi custom o moduli collegati alla visualizzazione delle categorie.

4. Testa la navigazione per filtri dopo l'aggiornamento

Dopo aver applicato la patch, verifica le categorie principali, i filtri per prezzo, attributi e caratteristiche, le pagine con molte combinazioni e il comportamento su dispositivi mobili. Controlla anche gli URL indicizzati dai motori di ricerca, perché la ricerca a faccette genera spesso molte varianti di pagina.

5. Analizza log e prestazioni

Un aggiornamento di sicurezza è anche l'occasione per osservare i log del server, gli errori PHP, le query lente e i picchi di traffico. Se noti molte richieste ripetute su URL con parametri di filtro anomali, potrebbe essere necessario aggiungere una protezione specifica contro bot e scraper.

Il rischio non si esaurisce con la patch: l'abuso della funzionalità

Anche dopo aver aggiornato alla 4.0.4 e rimosso la vulnerabilità di iniezione, la ricerca a faccette rimane esposta a un rischio operativo diverso: il suo abuso da parte di sistemi automatizzati. Bot distribuiti, scraper AI e crawler aggressivi possono generare combinazioni sempre diverse di parametri filtro, creando un carico non previsto sul database che rallenta le pagine per gli utenti reali.

Questo scenario prescinde dalla vulnerabilità specifica: riguarda il comportamento normale del modulo sotto pressione anomala. Un catalogo può essere scansionato con migliaia di richieste in pochi minuti, saturando risorse che dovrebbero servire utenti reali e processi commerciali.

Protezione specifica per la ricerca a faccette

Per chi desidera aggiungere un livello di difesa operativa dedicato, abbiamo sviluppato Faceted Search Rate Limiter – Protezione da bot e scraper AI per PrestaShop. Il modulo protegge la ricerca a faccette da bot distribuiti e scraper AI che generano milioni di combinazioni uniche sul parametro ?q=, con il rischio di saturare il database.

La logica è complementare all'aggiornamento ufficiale: non sostituisce la patch, ma aggiunge un controllo operativo sul modo in cui la ricerca viene utilizzata. Due livelli di difesa indipendenti — fingerprinting del bot per punteggio e rate limiting per IP — permettono di intervenire sul comportamento anomalo prima che diventi un problema di stabilità. Compatibile con PrestaShop 1.7 – 9.x.

Difesa più ampia contro bot, scraper e richieste sospette

La sicurezza della ricerca a faccette va inserita in una strategia più ampia. Un bot che colpisce il modulo dei filtri può tentare anche altre aree del sito: pagine prodotto, endpoint noti, URL di moduli, form pubblici o percorsi comuni.

Per questo può essere utile valutare PrestaShop Security & Bot Shield – anche con AbuseIPDB, pensato per bloccare accessi sospetti, spammer, bot di raccolta dati, scraper AI e tentativi di hacking. L'integrazione con AbuseIPDB, le blacklist IP e le regole avanzate permettono di costruire un filtro coerente tra traffico legittimo e richieste potenzialmente dannose, riducendo l'esposizione quotidiana prima che le richieste raggiungano le funzioni più delicate del negozio.

Non dimenticare la sicurezza del Back Office

Quando si parla di aggiornamenti di sicurezza, il front office riceve molta attenzione perché è visibile al pubblico. Tuttavia il Back Office resta una delle aree più critiche. Un accesso amministrativo compromesso può avere conseguenze su catalogo, ordini, clienti, configurazioni e moduli installati.

Per rafforzare questa parte, consigliamo di valutare Admin Login Monitor + 2FA per PrestaShop. Il modulo monitora ogni accesso al Back Office, registra login riusciti e falliti, rileva cambi IP sospetti e introduce un sistema 2FA TOTP progettato per agenzie, multi-shop e team tecnici. Particolarmente utile quando più persone o fornitori esterni accedono al pannello amministrativo.

Una checklist pratica dopo l'advisory GHSA-m5f5-28qr-9g9r

• Leggi l'avviso ufficiale: consulta la pagina GitHub dell'advisory per le informazioni complete e aggiornate.
• Controlla la versione di ps_facetedsearch: se è tra 3.0.0 e 4.0.3, il sistema è vulnerabile.
• Aggiorna alla versione 4.0.4 tramite il Gestore Moduli di PrestaShop.
• Se non puoi aggiornare subito: rimuovi i filtri a cursore (prezzo/peso) dal front office e applica la correzione manuale su src/Filters/Block.php.
• Controlla la directory del modulo per file PHP inattesi, segnale di possibile compromissione precedente.
• Prepara un backup prima di qualsiasi intervento.
• Testa filtri e categorie dopo l'aggiornamento.
• Analizza i log: cerca pattern di serializzazione PHP nei parametri URL (O:, ;i:, Monolog\).
• Applica rate limiting mirato: valuta una protezione specifica per la ricerca a faccette se il catalogo riceve traffico automatizzato intenso.
• Rafforza il Back Office: attiva monitoraggio accessi e autenticazione a due fattori.
• Documenta l'intervento: annota data, versione precedente, versione aggiornata, test effettuati e anomalie riscontrate.

Come impostare una manutenzione di sicurezza più efficace

L'aggiornamento di ps_facetedsearch è un buon esempio di come la sicurezza ecommerce non sia un'attività occasionale. Un negozio PrestaShop dovrebbe prevedere controlli periodici su core, moduli, tema, server, log e accessi amministrativi. La frequenza dipende dalla complessità del progetto, ma l'approccio deve essere costante.

Una manutenzione efficace include anche la valutazione del traffico. Se un negozio riceve molte visite da crawler, comparatori o sistemi di scraping, è importante distinguere ciò che genera valore da ciò che consuma risorse senza portare benefici. Non sempre serve bloccare tutto: spesso è sufficiente limitare, filtrare e rendere più sostenibile il carico.

Conclusione: aggiornare subito, poi proteggere meglio

L'avviso GHSA-m5f5-28qr-9g9r è critico nel senso tecnico del termine: CVSS 10.0, esecuzione di codice remoto non autenticata, versioni vulnerabili dalla 3.0.0 in poi. La prima azione è aggiornare ps_facetedsearch alla versione 4.0.4 e verificare che la directory del modulo non contenga file compromessi. Subito dopo, conviene osservare il traffico reale e valutare se la ricerca a faccette è esposta a richieste automatizzate eccessive.

Un ecommerce sicuro non dipende da una sola patch. Dipende da aggiornamenti tempestivi, protezione contro bot e scraper, monitoraggio degli accessi, log leggibili e procedure tecniche documentate. In questo modo la sicurezza diventa parte della gestione quotidiana del negozio, non un intervento d'emergenza da affrontare solo quando compare un advisory.