Kort sagt: Den PrestaShop-sårbarhed, der pt. fylder overskrifterne, er PHP2Shell og sidder i PHP, ikke i shoppen. En PrestaShop-opdatering hjælper ikke mod den. Efter PHP-rettelse og genstart bør I kontrollere mappen override, modulerne, checkout og medarbejderkontiene.
Hvad PHP2Shell betyder for PrestaShop-forhandlere
PrestaShop er en PHP-applikation, der er udbredt hos små og mellemstore forhandlere, ofte på shared hosting eller simple vServere. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode på afstand uden login, uafhængigt af shoppens status.
For en shop står der meget på spil: kundekonti, adresser, ordrer, fakturaer og adgange til betalings- og forsendelsestjenester. Angribere sigter ved shops ofte mod checkout, hvor de kan læse betalingsindtastninger med, før de når frem til betalingsudbyderen.
Hertil kommer tidsfaktoren. Ifølge medieberetninger blev et første angrebsforsøg observeret den 17.10.2026, rettelserne udkom den 21.10.2026. En shop, der var tilgængelig i den periode, kan være berørt, selv om alt ser normalt ud i dag. Bekræftede Indicators of Compromise findes der hidtil ikke; tegn fremgår af usædvanlig adfærd, nye filer og ændringer i databasen.
PrestaShop-sårbarhed: kontrollér PHP-versionen i Back Office
Under Avancerede indstillinger > Information viser PrestaShop server- og PHP-oplysninger for den kørende installation. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Hostingudbydere indspiller nogle gange rettelser som backport, det viste nummer forbliver så det samme. Lad jer bekræfte status skriftligt.
Hvilke PHP-versioner jeres PrestaShop-version understøtter, kontrollerer I ifølge systemkravene i producentens dokumentation på prestashop.com. Ældre shops i versionerne 1.6 og 1.7 kører ofte på ældre PHP-versioner; så gælder det, der står under Akutte foranstaltninger uden patch, indtil en opgradering er mulig.
Typiske skjulesteder for skadelig kode i PrestaShop
| Sted | Indhold | Kontrolpunkt |
|---|---|---|
app/config/parameters.php (ældre versioner config/settings.inc.php) |
Databaseadgang, cookie-nøgle | Ændringsdato, forny ved mistanke |
override/ |
overskrevne klasser og controllere | hver fil skal kunne forklares |
modules/ |
Moduler fra marketplace og fra tredjepartsudbydere | ukendte moduler, ændrede filer |
themes/ |
Skabeloner og JavaScript, også til checkout | fremmede scripts |
img/, upload/, download/ |
Billeder, kunde-uploads, digitale produkter | ingen PHP-filer |
var/cache/, var/logs/ |
Cache og logfiler | sikre logs, generér cache på ny |
install/ |
Installationsmappe | må ikke findes i drift |
Mappen override fortjener særlig opmærksomhed. Kode, der er lagt dér, erstatter dele af PrestaShop, for eksempel ordre- eller betalingsbehandlingen, og fjernes ikke automatisk ved opdateringer.
Ufarlige kontroller på kommandolinjen og i databasen (tabelpræfiks afhængigt af installationen):
find override -name "*.php" -newermt "2026-10-17"
find img upload download -type f -name "*.php"
ls -d admin*
SELECT email, firstname, lastname, active FROM ps_employee;
Melder kunder usædvanlige betalingssider eller kortmisbrug efter et køb, så tag checkout af nettet og sikr logs fra 20.10.2026. En manipuleret checkout kan opsnappe data ved hvert yderligere køb.
Back Office, medarbejderkonti og moduler
Back Office ligger i en mappe med et individuelt navn, som tildeles ved installationen. Kontrollér under Avancerede indstillinger medarbejderkonti og profiler for ukendte eller forladte adgange, f.eks. fra tidligere bureauer. Begræns om muligt admin-mappen til kendte netværk.
Moduler fra marketplace og fra tredjepartsudbydere udvider betaling, forsendelse, marketing og grænseflader. Hvert modul er yderligere PHP-kode, og moduler uden aktiv vedligeholdelse hører til de hyppigste indgange i PrestaShop-shops. Afinstallér og slet det ubrugte i stedet for blot at deaktivere det. Også webservice-nøgler til API'et bør I kontrollere for ukendte poster.
Hvad en PrestaShop-opdatering kan, og hvad den ikke kan
En opdatering af PrestaShop eller enkelte moduler lukker fejl i denne kode. Den patcher ikke PHP, genstarter ikke processer og fjerner hverken overrides eller fremmede moduler, scripts i temaet eller nye medarbejderkonti. Er der opsnappet personoplysninger, kan der desuden bestå en anmeldelsespligt; generelle oplysninger findes i GDPR-anmeldelsespligt: 72 timer, vurderingen i det enkelte tilfælde overtager jeres databeskyttelsesrådgiver. Hvad forhandlere ud over det bør være opmærksomme på, opsummerer IT-sikkerhed for onlineshops.
Ved shops med flere lande eller multistore-funktion kører der ofte flere domæner på den samme installation. Et fund berører så alle shops, selv om uregelmæssigheden kun er bemærket i én.
Hvordan hjælper PHP SOS konkret?
- Vi afklarer sammen med jeres hostingudbyder PHP-status, backport og genstart.
- Vi sikrer logs, filer og database og dokumenterer udgangstilstanden.
- Vi kontrollerer overrides, moduler, tema, upload-mapper, medarbejderkonti og webservice-nøgler.
- Ved fund overtager vores fjernelse af malware oprydningen og fornyelsen af adgangene.
Ofte stillede spørgsmål
Lukker en PrestaShop-opdatering PHP2Shell?
Nej. PrestaShop-opdateringer udbedrer fejl i shoppens kode. PHP2Shell-sårbarhederne ligger i PHP-fortolkeren og lukkes kun af en PHP-opdatering eller en bekræftet backport med genstart af alle PHP-processer.
Hvor ser jeg PHP-versionen i PrestaShop?
I Back Office under Avancerede indstillinger > Information. Dér står server- og PHP-oplysninger. En indspillet backport kan ikke ses af nummeret; det bekræfter jeres hostingudbyder.
Hvad er override-mappen, og hvorfor skal den kontrolleres?
I mappen override kan PrestaShops klasser og controllere overskrives. Kode dér kører i stedet for originalen, f.eks. i checkout. Ukendte overrides er derfor et vigtigt kontrolpunkt ved mistanke.
Skal admin-mappen være omdøbt?
PrestaShop tildeler ved installationen admin-mappen et eget navn. Det gør den sværere at finde, men erstatter hverken stærke adgangskoder, totrinsgodkendelse eller en adgangsbegrænsning.