PrestaShop CVE-2026-44212: l'XSS che arriva dal form Contattaci

C'è un modulo che ogni e-commerce considera poco importante: il form "Contattaci". Su PrestaShop, fino al 28 aprile 2026, quel form era la porta d'ingresso per uno Stored XSS critico (CVSS 9.3) che faceva girare JavaScript dentro la sessione di chi apriva il ticket nel back-office. La CVE-2026-44212 (alias GHSA-w9f3-qc75-qgx9) è stata divulgata il 4 maggio: se gestisci un negizio on line PrestaShop e non hai ancora aggiornato a 8.2.6 o 9.1.1, sei potenzialmente esposto.

Cos'è successo

Il 28 aprile 2026 PrestaShop ha rilasciato in parallelo le due versioni di sicurezza 8.2.6 e 9.1.1 per riparare una vulnerabilità segnalata da Savio di Doyensec in collaborazione con Anthropic Research. L'advisory ufficiale (GHSA-w9f3-qc75-qgx9) è stato pubblicato il 4 maggio 2026 con il CVE assegnato dopo: CVE-2026-44212, CVSS 9.3, vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N.

In parole povere: attacco via rete, senza autenticazione, senza privilegi, con una sola interazione richiesta da un utente fidato (il dipendente che apre il ticket). Impatto su confidenzialità e integrità: alto.

Come funziona l'attacco

Il bug vive nel modulo Customer Service del back-office, nel template che mostra il thread del cliente. L'advisory ufficiale lo dice in modo chiaro: il contenuto email del thread veniva renderizzato senza HTML escaping in due punti: il titolo del form di risposta (un <h3>) e un campo input nascosto.

La catena di attacco è la seguente:

1. Un malintenzionato non autenticato apre il form pubblico "Contattaci" del sito.
2. Inserisce un indirizzo email valido secondo RFC 5321 ma con il local part in formato "quoted-string". Questa sintassi RFC-compliant ammette caratteri (virgolette, spazi, simboli) che la validazione "loose" di PrestaShop accettava senza problemi. Dentro alle virgolette finisce un payload JavaScript.
3. L'email entra in database, intatta, dentro al thread del cliente.
4. Quando un operatore del back-office apre il ticket (è il suo lavoro, lo apre senza pensarci), il template stampa l'email nell'<h3> e nell'input nascosto. Il browser interpreta il payload come HTML/JS e lo esegue dentro la sessione admin.
5. Da qui il malintenzionato ha via libera: estrarre cookie di sessione, creare un nuovo account admin via AJAX sull'API admin, iniettare un webshell tramite l'editor moduli. Account takeover completo dello store.

Il punto narrativo della vicenda è semplice: il vettore non è un modulo terzo sospetto e nemmeno un endpoint dimenticato. È il form di contatto, che ogni store ha per definizione, e che ogni customer service apre come parte normale delle attività quotidiane.

Perché la validazione "loose" non bastava

PrestaShop usa la classe Validate per controllare gli input. Per il campo email esistono due modalità: loose (storica, permissiva) e strict (più aderente alle restrizioni reali del mondo SMTP). La modalità loose lasciava passare i local part quoted-string, RFC-leciti ma in pratica usati pochissimo nel traffico reale.

La patch fa due cose insieme:

1. Escape lato output: nei due punti del template incriminato l'email viene passata attraverso il modifier escape di Smarty.
2. Hardening lato input: la validazione dell'email passa da loose a strict, riducendo la superficie di sintassi RFC-rare che venivano accettate.

Né l'output escaping da solo né la validazione stretta da sola sarebbero sufficienti a chiudere i problemi. Insieme sì.

Versioni colpite e patch

Le versioni meno recenti (1.7, 8.0, 8.1) non ricevono più patch ufficiali e dovrebbero essere migrate. Se sei su 9.0.x, l'unica versione supportata è 9.1.1.

Cosa fare oggi sul tuo PrestaShop

In ordine di rischio decrescente:

1. Aggiorna subito alla versione patchata. È l'opzione più sicura. Su 8.2.x vai a 8.2.6, su 9.1.x vai a 9.1.1. Usa l'Update Assistant ufficiale e fai un backup completo (database + file) prima di iniziare. Tempo richiesto su uno negozio medio: 20-40 minuti incluso il rollback plan.
2. Se non puoi aggiornare oggi, installa l'hotfix module. PrestaShop ha pubblicato pshotfix_ghsaw9f3qc75qgx9, un modulo che applica solo la patch di sicurezza senza toccare il resto del core. Lo trovi linkato direttamente dall'advisory ufficiale.
3. Patch manuale come ultima risorsa. Se hai un core customizzato e non puoi nemmeno installare il modulo hotfix, devi modificare a mano due punti: applicare il modifier escape di Smarty alle due occorrenze dell'email nel template customer threads, e cambiare la validazione email in Validate.php da loose a strict. Documenta la modifica in un commit dedicato così non la perdi al prossimo upgrade.
4. Controlla i log subito. Cerca nei thread del Customer Service email con virgolette, simboli <, >, script, onerror, javascript:. Se trovi qualcosa, isola il sistema, ruota le credenziali admin, revoca le sessioni attive e ispeziona la lista utenti amministrativi per account creati negli ultimi 30 giorni che non riconosci. La data di disclosure pubblica è del 4 maggio, ma chi ha trovato il bug per primo lo conosceva già da prima.
5. Audit dei moduli che leggono email da thread. Se hai estensioni custom o di terzi che fanno render del campo email del cliente senza passare per Smarty, hanno lo stesso problema indipendentemente dalla patch core.

Cosa significa per chi gestisce un e-commerce su SpazioRC

Se il tuo store gira su un nostro Cloud Server o su un piano hosting condiviso, l'aggiornamento è una tua responsabilità: PrestaShop non viene aggiornato a livello server come cPanel o il kernel. Tre punti pratici:

• Pianifica l'update in finestra quando il traffico del tuo sito è ridotto ma non rimandarlo: ogni giorno in più con il form Contattaci vulnerabile è una giornata in cui un bot di scansione automatica può consegnare il payload.
• Tieni traccia della versione PrestaShop nella tua documentazione interna. Sapere a colpo d'occhio "tutti i negozi del cliente X sono su 8.2.6+" trasforma un advisory di questo tipo da emergenza a routine.
• Se vendi servizi di manutenzione, questa è la classica CVE che giustifica il contratto: il merchant non legge i security advisory di PrestaShop, ma il danno di un account takeover su uno store con ordini in corso è altissimo (frodi sui rimborsi, pagamenti deviati, defacement, perdita di reputazione).

In sintesi

CVE-2026-44212 non è una vulnerabilità esotica. È un buon promemoria che le superfici di attacco "noiose" (un form di contatto, un campo email, un template di reply nel back-office) sono spesso quelle che fanno più male. Aggiorna a 8.2.6 o 9.1.1 oggi, controlla i thread aperti per email sospette, e usa questa occasione per aggiornare il processo di patch management sui tuoi negozi prestashop.