E-commerce e PrestaShop // Pubblicato PrestaShop

PrestaShop 9.2.1 e 8.2.9: 18 vulnerabilità chiuse, cosa fare sul tuo negozio

Il 9 novembre 2026 PrestaShop ha corretto 18 vulnerabilità, 15 di gravità alta, alcune sfruttabili senza account. Quali riguardano davvero il tuo negozio, come aggiornare senza rompere nulla e cosa fare subito se non puoi aggiornare oggi.

11 novembre 2026 5 min di lettura

Il 9 novembre 2026 PrestaShop ha pubblicato due aggiornamenti di sicurezza: 9.2.1 per il ramo 9 e 8.2.9 per il ramo 8.2. Insieme chiudono 18 vulnerabilità, 15 di gravità alta. Alcune si possono sfruttare senza nessun account sul negozio. Il progetto raccomanda di aggiornare il prima possibile.

Diciotto avvisi tutti insieme fanno paura, ma non pesano tutti allo stesso modo. Qui sotto li dividiamo per chi può sfruttarli, che è la domanda che conta per decidere quanto in fretta muoversi.

Le versioni da installare

Se hai	Aggiorna a	Vulnerabilità chiuse
PrestaShop 9.x	9.2.1	18 (15 alte)
PrestaShop 8.2.x	8.2.9	15 (12 alte)
PrestaShop 1.7 o precedente	nessun aggiornamento	va pianificata la migrazione

Tre delle diciotto riguardano solo il ramo 9: le due dell’API di amministrazione e quella della modalità debug. Le altre quindici sono corrette in entrambi i rami.

Con la versione arrivano anche due moduli aggiornati, installabili anche da soli dal gestore dei moduli:

ps_emailsubscription 3.0.1 (newsletter): un indirizzo che comincia con un carattere da formula veniva esportato così com’era nel CSV degli iscritti, e poteva diventare una formula quando l’amministratore apriva il file in un foglio di calcolo;
psgdpr 1.4.4 (GDPR): chiunque, anche senza account, poteva registrare un consenso a nome di un altro cliente nel registro GDPR.

Le più urgenti: quelle dal lato del negozio

Installer. Due vulnerabilità colpiscono l’installazione web, la cartella install usata la prima volta che si configura il negozio:

l’installer non controllava se il negozio era già installato, quindi chiunque poteva rilanciarlo e sovrascrivere la configurazione;
l’installer ricostruiva la sessione da un cookie senza verificarne il contenuto: un visitatore con un cookie costruito ad arte poteva eseguire codice sul server.

Tutte e due servono solo se la cartella dell’installer è ancora raggiungibile dal web. PrestaShop chiede di cancellarla a fine installazione, ma capita di trovarla ancora lì, soprattutto dopo un trasloco o su una copia di prova.

Controllo da fare adesso: apri https://il-tuo-negozio.it/install/. Se compare l’installazione, sei esposto: cancella la cartella dal server prima ancora di aggiornare.

File di personalizzazione. Chi conosceva il riferimento di un ordine poteva scaricare i file caricati dal cliente per personalizzare un prodotto, come foto o loghi da stampare. Ora serve anche la chiave segreta dell’ordine.

Reset della password. Il codice per reimpostare la password di un cliente era ricavato da valori prevedibili: chi conosceva la chiave segreta del cliente poteva indovinarlo e prendersi l’account.

Codici sconto e ordini doppi. Con più richieste nello stesso istante un cliente poteva usare un codice sconto più volte di quante consentite, oppure creare più ordini gratuiti dallo stesso carrello. Sono due problemi di concorrenza (race condition): bastano un carrello e un po’ di automazione, non danno accesso al server ma toccano direttamente i conti.

Chi ha una chiave del webservice

Il webservice è l’API classica di PrestaShop, quella che usano gestionali, marketplace e sincronizzazioni di magazzino. Tre vulnerabilità riguardano chi possiede una chiave:

una chiave con permesso di scrittura sugli allegati poteva leggere o cancellare file fuori dalla cartella dei download (completa la correzione di una vulnerabilità del 2023, CVE-2023-39529);
nelle installazioni multinegozio, una chiave limitata a un negozio poteva arrivare ai clienti di un altro, fino a prenderne gli account;
sempre in multinegozio, aggiungere id_shop=all alla richiesta faceva superare i limiti della chiave.

Se il webservice non lo usi, è spento e queste tre non ti toccano. Se lo usi, è il momento di contare le chiavi attive e togliere quelle che nessuno ricorda più.

Chi entra nel back office

Sette vulnerabilità richiedono un account dipendente nel pannello di amministrazione, più due dell’API di amministrazione. Quasi tutte portano allo stesso risultato: eseguire codice sul server partendo da una funzione del pannello.

importazione di temi e moduli da archivio o da URL;
pagina delle traduzioni e traduzioni delle email;
campi dei cookie nella modalità debug (solo ramo 9);
file SVG con script nascosti caricati come logo o nel file manager, che poi eseguono JavaScript nel browser di chi li apre, compresi altri dipendenti;
un dipendente con solo il permesso di creare ordini poteva modificare quelli esistenti.

Sembrano rischi minori, perché servono credenziali. In pratica non lo sono: una sessione di back office rubata da un infostealer sul PC di un dipendente vale quanto la password, e da qui si arriva al server. Ne parliamo nella guida sugli infostealer.

Admin API (solo ramo 9). Un client autorizzato a gestire i client API poteva darsi da solo qualsiasi permesso, fino all’esecuzione di codice. Inoltre disattivare un client o revocarne i token non bloccava i token già emessi.

Come aggiornare senza rompere il negozio

Backup completo, file e database, e prova a ripristinarlo almeno una volta su una copia. Un backup mai ripristinato è una speranza, non un backup.
Aggiorna su una copia di prova, se ce l’hai. Il salto da 9.2.0 a 9.2.1 è un rilascio di manutenzione, senza cambiamenti incompatibili, ma i moduli di terze parti restano l’incognita.
Usa l’Update Assistant (il modulo autoupgrade) aggiornato all’ultima versione, dal pannello o da riga di comando.
Dopo l’aggiornamento controlla tre cose: che la modalità sviluppo sia di nuovo spenta, che la cache sia stata svuotata, e che un ordine di prova arrivi fino al pagamento. Login e registrazione clienti vanno provati a mano: sono le prime cose che un modulo incompatibile rompe.
Aggiorna i moduli newsletter e GDPR, se il gestore dei moduli non l’ha già fatto.

Se oggi non puoi aggiornare

Non sostituiscono l’aggiornamento, ma riducono il rischio intanto:

cancella la cartella install se esiste ancora: chiude le due vulnerabilità peggiori;
spegni il webservice se non lo usi, oppure revoca le chiavi che non servono;
riduci gli account del back office al minimo, togli i permessi su temi, moduli e traduzioni a chi non li usa e attiva l’autenticazione a due fattori;
controlla i log per richieste a /install/ o con id_shop=all.

Il punto

Questa volta la parte del codice principale è stata corretta in un colpo solo e con avvisi chiari. Nella nostra esperienza il rischio più grande per un negozio PrestaShop resta però altrove: nei moduli di terze parti, spesso dimenticati, che nessun rilascio del progetto può correggere. Ne parliamo nella guida sui moduli PrestaShop vulnerabili.

Aggiorna, cancella l’installer se c’è ancora, e approfitta del backup per fare l’inventario dei moduli.