Pe 9 noiembrie 2026, PrestaShop a publicat două versiuni de securitate în aceeași zi: 9.2.1 închide optsprezece avertizări de securitate, iar 8.2.9 închide cincisprezece. Ambele conțin doar remedieri, fără funcții noi.
O parte dintre remedieri opresc execuția de cod pe server fără autentificare. Altele se simt direct în bani: dintr-un singur coș puteau apărea două comenzi, iar un voucher putea fi folosit peste limita stabilită. Articolul trece prin ce permitea fiecare problemă, ce ramură este afectată și ce se poate face când actualizarea nu încape acum.
Nu mă pricep la partea tehnicăPe scurt: ce s-a întâmplat și ce este de făcut
PrestaShop a reparat un set de probleme prin care persoane din afară puteau ajunge la administrarea magazinului, la datele clienților sau chiar la server. Remedierile au apărut în două versiuni noi: 9.2.1 pentru ramura 9 și 8.2.9 pentru ramura 8.2.
Remedierile ajung pe magazin odată cu actualizarea. Actualizarea în sine durează puțin, dar tema și modulele trebuie testate după, așa că de obicei o face cel care întreține magazinul.
De făcut: întrebați persoana care întreține magazinul ce versiune rulează și când urcă remedierile. Dacă nu există cineva care să îl întrețină, textul de mai jos poate fi trimis ca atare.
Întrebări pentru cel care întreține magazinul
Ce versiune de PrestaShop rulează pe magazin? Este instalată versiunea de securitate din 9 noiembrie 2026 (9.2.1, respectiv 8.2.9), iar dacă nu, când urcă? Dacă actualizarea nu este posibilă acum, ce soluție intermediară există? Magazinul folosește chei de webservice și, dacă da, pe ce magazine este valabilă fiecare cheie?
Ce repară 9.2.1 și 8.2.9?
Versiunea 9.2.1 închide optsprezece avertizări, iar 8.2.9 cincisprezece. Majoritatea remedierilor au ajuns în ambele ramuri. Trei privesc doar ramura 9, pentru că țin de Admin API și de setarea de depanare de acolo.
| Remediere | Ce permitea | Gravitate | Ramura |
|---|---|---|---|
| Admin API: acordarea oricărui drept GHSA-p292-3rh4-vm4p | un client API cu dreptul api_client_write își putea acorda orice drept, ceea ce duce la execuție de cod | 8,8 | doar 9 |
| Încărcare SVG în managerul de fișiere și la siglă GHSA-99cp-c6mm-p7h5 | codul din fișierul SVG încărcat se executa în administrare (XSS stocat) | 8,7 | 8 și 9 |
| Atașamente: ieșirea din folderul de descărcare GHSA-wrmc-gmx5-9hhc | fișierele din afara folderului puteau fi citite și șterse | 8,5 | 8 și 9 |
| Instalator: injectare de obiect în cookie GHSA-h2q4-7fp7-m5jp | execuție de cod pe server fără autentificare | 8,1 | 8 și 9 |
| Rularea din nou a instalatorului GHSA-8rxw-79mh-gmm5 | setările unui magazin deja instalat puteau fi suprascrise | 8,1 | 8 și 9 |
| Webservice: preluarea clientului altui magazin CVE-2026-71519 | cheia unui magazin ajungea la datele clientului din alt magazin | 8,1 | 8 și 9 |
Webservice: id_shop=allCVE-2026-71531 | cheia citea date și dincolo de magazinele permise | 8,1 | 8 și 9 |
| Câmpurile cookie-ului de depanare GHSA-95f5-jc9c-gg3q | un angajat cu dreptul Performanță putea executa cod PHP | 7,2 | doar 9 |
| Pagina de traduceri, importul de teme și module, traducerile de e-mail GHSA-fxq4-2mc8-99pr, GHSA-7q68-ch46-pxmc, GHSA-95w6-v2wq-cv8w, GHSA-5p6p-mx64-96jf | un administrator autentificat putea scrie fișiere în afara folderului țintă, ceea ce duce la execuție de cod | 7,2 | 8 și 9 |
| Două comenzi dintr-un singur coș GHSA-2676-hc74-gg7v | într-o condiție de cursă, același coș devenea două comenzi | 7,5 | 8 și 9 |
| Ocolirea limitei voucherului GHSA-r246-6gw4-pj3p | voucherul putea fi folosit peste numărul de utilizări stabilit | 7,5 | 8 și 9 |
| Dezactivarea Admin API rămânea fără efect GHSA-6c2j-pgwm-95m9 | dezactivarea clientului API și retragerea jetonului nu intrau în vigoare | 7,1 | doar 9 |
| Descărcarea fișierului personalizat GHSA-fg9q-mm4c-h5xc | fișierul încărcat de client putea fi obținut cu referința comenzii, fără autentificare | 5,9 | 8 și 9 |
| Jetonul de resetare a parolei GHSA-g6p7-cx52-hcrj | jetonul era previzibil și permitea preluarea contului | 4,8 | 8 și 9 |
Gravitatea este scorul CVSS din avertizările PrestaShop, pe o scară de la 0 la 10. Cele două versiuni actualizează și modulul psgdpr la 1.4.4, iar modulul de newsletter la 3.0.1.
Ce remedieri ating comenzile și încasările?
Două dintre remedieri nu țin de intruziune, ci de felul în care se comportă finalizarea comenzii. Una împiedică transformarea aceluiași coș în două comenzi într-o condiție de cursă. În practică înseamnă o comandă facturată de două ori și livrată de două ori, cu stocul și numerotarea facturilor date peste cap.
Cealaltă privește limita de utilizare a voucherelor: în condiția de cursă din validarea comenzii, voucherul putea fi folosit peste numărul de utilizări stabilit. Un voucher generos, gândit pentru o singură folosire, putea fi astfel valorificat de mai multe ori.
Dacă au apărut deja comenzi duplicate sau un voucher folosit mai des decât era prevăzut, istoricul comenzilor merită verificat chiar înainte de actualizare: remedierea împiedică situațiile noi, nu desface comenzile deja create.
La ce să fie atente instalările cu mai multe magazine?
Două remedieri privesc instalările care deservesc mai multe magazine dintr-un singur cod. Ambele țin de API-ul webservice, prin care sistemele externe, de exemplu programul de facturare sau cel de gestiune, ajung la magazin.
CVE-2026-71519 descrie cum o cheie emisă pentru un magazin ajungea la fișa clientului din alt magazin, pentru că verificarea magazinului lipsea la nivel de înregistrare. CVE-2026-71531 permitea ca o cerere cu id_shop=all sau id_shop_group să iasă din setul de magazine pentru care cheia era validă.
Acolo unde o instalare deservește mai multe branduri sau mai multe țări, iar parteneri externi dețin chei, după actualizare merită verificate și cheile: pe ce magazine este valabilă fiecare și la ce resurse ajunge.
Ce se poate face dacă actualizarea nu este posibilă acum?
Actualizarea atinge tema și modulele, așa că pe multe magazine nu se poate face în aceeași zi. Versiunea 8.2.9 aparține ramurii 8.2; pentru ramurile 8.0 și 8.1 nu a apărut o versiune în acea zi, la fel nici pentru magazinele mai vechi, pe 1.7.
În acest caz remedierile pot fi aduse în versiunea aflată în funcțiune: fișierele vizate se modifică după varianta reparată, restul magazinului rămâne neschimbat. Acest lucru îl face modulul Remedieri de securitate pentru PrestaShop, care face o copie de siguranță înainte, astfel încât fiecare remediere să poată fi anulată. Ce probleme ating un anumit magazin arată modulul Scanare de securitate pentru PrestaShop.
Soluția de durată rămâne actualizarea pe o ramură susținută, pentru că doar acolo ajunge de la sine și remedierea următoare.
Ce merită făcut acum?
- Verificarea versiunii în administrare, la Parametri avansați > Informații. Pe ramura 9 versiunea reparată este 9.2.1, pe 8.2 este 8.2.9.
- Actualizarea, după un test. Versiunea conține doar remedieri, dar tema și modulele merită încercate întâi pe o copie.
- Verificarea conturilor din administrare: cine ajunge la pagina Performanță și la cea de traduceri și dacă a rămas vreun cont de angajat nefolosit. O parte dintre problemele reparate presupun un utilizator autentificat.
- Verificarea cheilor de webservice: pe ce magazine este valabilă fiecare cheie și dacă mai este folosită de cineva.
- Dacă actualizarea nu încape acum, aducerea remedierilor în versiunea curentă, cu copie de siguranță.
Întrebări frecvente
[faq]
Q: De unde aflu ce versiune de PrestaShop rulează pe magazin?
A: Din administrare, la Parametri avansați > Informații. Versiunile reparate sunt 9.2.1 pe ramura 9 și 8.2.9 pe 8.2.
Q: Este suficient să actualizez modulele?
A: Nu. Aproape toate remedierile sunt în codul PrestaShop; versiunea actualizează în plus două module (psgdpr 1.4.4, newsletter 3.0.1).
Q: Cât de urgent este?
A: Două dintre cele mai grave remedieri închid probleme care funcționează fără autentificare, iar descrierile sunt publice, așa că actualizarea nu ar trebui amânată cu săptămâni. Avertizările nu menționează cazuri de exploatare.
Q: Ce se întâmplă cu magazinele pe 8.0, 8.1 sau 1.7?
A: Pentru acele ramuri nu a apărut o versiune în acea zi. Remedierile pot fi aduse în versiunea curentă, iar pe termen lung rămâne actualizarea pe o ramură susținută.
Q: Instalarea deservește mai multe branduri. Este altceva de făcut?
A: Da. După actualizare merită verificate și cheile de webservice, pentru că două dintre remedieri există tocmai ca o cheie să rămână în magazinul ei.
Surse: Note de versiune PrestaShop 9.2.1, Note de versiune PrestaShop 8.2.9, Avertizări de securitate PrestaShop
