Carrello
Non ci sono più articoli nel tuo carrello
- Tecnoacquisti.com
- Blog sulla sicurezza online
- prestashop, Checkout, paypal
Security Advisory - Aprile 2026 - GHSA-w9f3-qc75-qgx9 - CWE-79 - Severity 9.3/10
Severità critica dichiarata, ma con importanti limitazioni pratiche che ne riducono il rischio reale nella maggior parte degli shop. Leggi l'analisi completa prima di allarmarti.
Severità critica dichiarata, ma con importanti limitazioni pratiche che ne riducono il rischio reale nella maggior parte degli shop. Leggi l'analisi completa prima di allarmarti.
[embed name="PrestaShop XSS Vulnerability Fix"]https://youtu.be/PLs4Fzwlt68[/embed]
A fine aprile 2026 PrestaShop ha comunicato in via riservata ai propri partner certificati la scoperta di una vulnerabilità di tipo Stored XSS nel pannello di amministrazione, specificamente nella sezione Servizio Clienti. Le versioni coinvolte sono PrestaShop 1.7.x, tutte le 8.x precedenti alla 8.2.6 e tutte le 9.x precedenti alla 9.1.1.
Abbiamo analizzato la vulnerabilità in dettaglio, condotto test pratici su ambienti reali e sviluppato un modulo di correzione gratuito e open source. In questo articolo condividiamo i risultati, con un'attenzione particolare ai limiti concreti di questo attacco - aspetto spesso trascurato nelle comunicazioni di sicurezza.
Cos'è una Stored XSS e perché riguarda il Servizio Clienti
Una vulnerabilità Stored XSS (Cross-Site Scripting persistente) si verifica quando un dato fornito da un utente esterno viene salvato nel database e successivamente mostrato in un'altra pagina senza essere adeguatamente sanificato. In questo caso specifico, il vettore è il campo email del form "Contattaci" del front office.
Un visitatore che invia un'email contenente caratteri speciali tipici del codice HTML/JavaScript potrebbe - in condizioni favorevoli - far sì che quei caratteri vengano interpretati come codice nel momento in cui un amministratore apre il messaggio nel back office. L'impatto teorico è significativo: uno script malevolo eseguito nella sessione dell'amministratore potrebbe leggere il cookie di sessione e trasmettere le credenziali a terzi.
La severità dichiarata di 9.3/10 riflette questo scenario peggiore e il fatto che l'attacco parta da un utente non autenticato (chiunque può compilare il form "Contattaci").
I limiti pratici: perché molti shop sono già protetti
Durante i nostri test su installazioni reali abbiamo riscontrato che nella grande maggioranza dei casi la vulnerabilità è già mitigata da misure preesistenti.
1. Validazione email di PrestaShop 8.x
Su PrestaShop 8.x, la funzione isEmail() in modalità predefinita rifiuta già le email contenenti il carattere " (doppio apice), che è il vettore principale di questo attacco. Nei nostri test il payload è stato respinto prima ancora di raggiungere il database, con un errore "E-mail non valida" restituito al mittente.
Su PrestaShop 8.x, la funzione isEmail() in modalità predefinita rifiuta già le email contenenti il carattere " (doppio apice), che è il vettore principale di questo attacco. Nei nostri test il payload è stato respinto prima ancora di raggiungere il database, con un errore "E-mail non valida" restituito al mittente.
2. Moduli reCAPTCHA e validazione email
La presenza di un modulo reCAPTCHA o di un sistema di validazione avanzata delle email sul form di contatto blocca l'invio automatico di payload. Senza poter superare il CAPTCHA, l'attacco non può essere automatizzato e richiede interazione manuale - riducendo drasticamente la sua scalabilità.
La presenza di un modulo reCAPTCHA o di un sistema di validazione avanzata delle email sul form di contatto blocca l'invio automatico di payload. Senza poter superare il CAPTCHA, l'attacco non può essere automatizzato e richiede interazione manuale - riducendo drasticamente la sua scalabilità.
3. Servizio Clienti non utilizzato o raramente aperto
Se il back office non viene usato per gestire i messaggi del Servizio Clienti, la finestra di esposizione si riduce ulteriormente. Lo script si esegue solo nel momento in cui un admin apre il ticket specifico.
Se il back office non viene usato per gestire i messaggi del Servizio Clienti, la finestra di esposizione si riduce ulteriormente. Lo script si esegue solo nel momento in cui un admin apre il ticket specifico.
4. PrestaShop 1.7 con moduli di protezione aggiuntivi
Su PrestaShop 1.7, dove la validazione email è più permissiva, la presenza di reCAPTCHA o di blacklist sui pattern email (blocco delle email contenenti <, >, ") è sufficiente a impedire che il payload raggiunga il database.
Su PrestaShop 1.7, dove la validazione email è più permissiva, la presenza di reCAPTCHA o di blacklist sui pattern email (blocco delle email contenenti <, >, ") è sufficiente a impedire che il payload raggiunga il database.
Scenari di rischio per configurazione
| Versione PS | reCAPTCHA / validazione email | Rischio reale | Azione consigliata |
|---|---|---|---|
| 8.x ≥ 8.2.5 | Qualsiasi | Basso | Aggiornare a 8.2.6 quando disponibile |
| 8.x < 8.2.5 | Presente | Basso | Applicare il modulo hotfix |
| 8.x < 8.2.5 | Assente | Medio | Applicare il modulo hotfix |
| 1.7.x | Presente | Basso | Applicare il modulo hotfix |
| 1.7.x | Assente | Alto | Applicare il modulo hotfix urgentemente |
Cosa corregge il modulo hotfix
Il modulo agisce su due livelli distinti, entrambi permanenti e indipendenti dalla sua installazione:
Fix 1 - Sanificazione del template BO (tutte le versioni)
Il template della pagina Servizio Clienti nel back office viene modificato per applicare correttamente l'escape HTML su tutti i campi che visualizzano dati provenienti dal database. Anche se un payload dovesse raggiungere il DB, verrebbe mostrato come testo e mai eseguito.
Il template della pagina Servizio Clienti nel back office viene modificato per applicare correttamente l'escape HTML su tutti i campi che visualizzano dati provenienti dal database. Anche se un payload dovesse raggiungere il DB, verrebbe mostrato come testo e mai eseguito.
Fix 2 - Validazione email rafforzata (PS 8.0.2+)
Su PrestaShop 8.0.2 e superiori, la modalità di validazione email viene portata da loose a strict. Su PrestaShop 1.7, viene iniettata una guardia specifica che blocca il carattere ".
Su PrestaShop 8.0.2 e superiori, la modalità di validazione email viene portata da loose a strict. Su PrestaShop 1.7, viene iniettata una guardia specifica che blocca il carattere ".
Scansione forense del database
Il modulo include una funzione di analisi del database che cerca pattern sospetti nelle tabelle dei clienti e dei messaggi, fornendo indicazioni immediate su eventuali tentativi di sfruttamento pregressi e le azioni correttive da intraprendere.
Il modulo include una funzione di analisi del database che cerca pattern sospetti nelle tabelle dei clienti e dei messaggi, fornendo indicazioni immediate su eventuali tentativi di sfruttamento pregressi e le azioni correttive da intraprendere.
Rilevamento override
Prima di applicare il fix su Validate.php, il modulo verifica se è presente un override del metodo isEmail(). In caso affermativo, la modifica automatica viene saltata e viene mostrato il codice da applicare manualmente, evitando conflitti con personalizzazioni esistenti.
Prima di applicare il fix su Validate.php, il modulo verifica se è presente un override del metodo isEmail(). In caso affermativo, la modifica automatica viene saltata e viene mostrato il codice da applicare manualmente, evitando conflitti con personalizzazioni esistenti.
Cosa fare adesso - in ordine di priorità
- Verificate la versione di PrestaShop di ogni shop che gestite (BO - Parametri Avanzati - Informazioni).
- Installate il modulo hotfix su tutti gli shop con versioni 1.7.x, 8.x < 8.2.6 e 9.x < 9.1.1.
- Eseguite la scansione forense dal pannello del modulo per verificare se ci sono stati tentativi pregressi.
- Aggiungete pattern di email vietate nel vostro modulo di validazione: bloccare le email contenenti <, > e " aggiunge un ulteriore layer di protezione.
- Pianificate l'aggiornamento alle versioni 8.2.6 / 9.1.1 non appena rilasciate ufficialmente da PrestaShop.
Modulo hotfix gratuito e open source
Il modulo tecno_xss_hotfix è disponibile gratuitamente su GitHub. Supporta PrestaShop dalla versione 1.7.0.0 alla 9.x, include scansione forense del database e rilevamento degli override. Il codice è pubblico e verificabile.
Scarica da GitHubNota: Questo articolo è scritto da Tecnoacquisti.com agenzia partner PrestaShop che ha ricevuto la comunicazione riservata anticipata della vulnerabilità. Le informazioni tecniche sono basate sull'analisi diretta del codice e su test condotti in ambienti controllati. Non vengono forniti dettagli sulle tecniche di attacco per non agevolare usi impropri. Per approfondimenti sulla vulnerabilità, fare riferimento al bollettino ufficiale di PrestaShop al momento della pubblicazione delle versioni 8.2.6 e 9.1.1.