Kort sagt: Er jeres onlineshop hacket, eller kører den på en upatchet PHP-version, handler det om tre ting på én gang: kundedata, checkout og jeres omsætning. Sæt shoppen kontrolleret i vedligeholdelsestilstand, sikr logs fra 20.10.2026, og afklar, hvem der opdaterer og genstarter PHP på jeres server.
Hvad der står på spil i en onlineshop
En shop er mere end et website. Den administrerer kundekonti med adgangskode-hashes, leverings- og faktureringsadresser, ordrehistorik, gavekort og ofte også grænseflader til varedisposition, fragtudbydere og markedspladser. Den, der kan udføre kode på serveren, kommer som regel til databasen og til de API-nøgler, der er gemt dér.
Kortdata ligger oftest ikke hos jer, men hos betalingsudbyderen. Det beroliger kun delvist: En angriber kan smugle JavaScript ind i bestillingsprocessen, som læser indtastninger med i browseren. Sådanne skimming-scripts bemærkes næppe i shopdriften, fordi bestillinger løber helt normalt igennem.
Dertil kommer grænsefladerne. En shop, der overdrager ordrer til varedisposition, fragtudbydere og markedspladser, gemmer som regel adgangsnøglerne hertil i konfigurationsfiler på serveren. Den, der kopierer dem, kan på forhandlerens vegne oprette fragtlabels, ændre lagerbeholdninger eller misbruge markedspladskonti.
Typiske shopsystemer og hvorfor PHP2Shell rammer dem
De udbredte shopsystemer i mellemstore virksomheder kører på PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop og mange ældre Shopware 5-installationer. PHP2Shell (CVE-2026-109618 og CVE-2026-109619, hver CVSS 9,2) ligger i selve PHP. Angribere har ikke brug for en kundekonto og ingen admin-adgang.
For forhandlere betyder det: Den nyeste shopopdatering beskytter ikke. Afgørende er, om PHP på serveren står på 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller om hostingudbyderen har indspillet en backport, og om alle PHP-processer derefter er genstartet. Ved gamle shops på PHP 8.1 eller ældre findes der ikke længere officielle opdateringer fra PHP-projektet. Så står der ved siden af nødsituationen en migrering, som I ikke vil gennemføre under tidspres i højsæsonen.
Onlineshop hacket: Hvad en hændelse konkret betyder
En kompromitteret shop forårsager skade på flere niveauer, som forstærker hinanden:
- Omsætning: Hver time i vedligeholdelsestilstand koster ordrer. En shop, der uset kører videre, kan dog blive betydeligt dyrere.
- Kundedata: Udslupne adresser og ordrer bruges til målrettede phishing-mails, der virker ægte, fordi de nævner rigtige ordrer.
- Synlighed: Genkender Google skadelig kode, vises en advarsel i søgeresultaterne. Hvordan I slipper af med den igen, står i vejledningen Fjern Google-advarsel.
- Partnere: Betalingsudbydere og markedspladser har egne regler for sikkerhedshændelser. Den, der melder for sent, risikerer problemer ved afregningen.
Hvem er ansvarlig: bureau, hostingudbyder eller forhandler?
I mange shops falder spørgsmålet om PHP mellem alle stole. Bureauet har bygget shoppen og vedligeholder plugins, hostingudbyderen driver serveren, og forhandleren går ud fra, at en af de to tager sig af det. Ved managed hosting patcher som regel hostingudbyderen, ved en egen vServer ingen automatisk.
| Opgave | Typisk ansvarlig | Kontrollér |
|---|---|---|
| Opdatere PHP-pakken | Hostingudbyder eller serverpasser | Skriftlig bekræftelse med pakkestatus |
| Genstarte PHP-processer | den, der administrerer serveren | Tidspunkt for genstarten |
| Shop og plugins | Bureau | Vedligeholdelsesaftale og adgange |
| Informere betalingsudbyderen | Forhandler | Kontraktlige anmeldelsespligter |
En PHP-rettelse beviser ikke, at der ikke skete noget før. Blev shoppen angrebet mellem 17.10. og tidspunktet for rettelsen, kan indsmuglet kode fortsat køre. Lad det kontrollere, før I giver afblæsning.
De første timer: rækkefølge for forhandlere
- Sæt shoppen i vedligeholdelsestilstand eller, hvis det ikke er muligt, tag den midlertidigt af nettet.
- Sikr webserver-, PHP- og shoplogs fra 20.10.2026, før rotation sletter dem.
- Lad hostingudbyderen skriftligt bekræfte PHP-pakkestatus og genstarten.
- Forny admin-adgangskoder, API-nøgler til betaling, fragt og markedspladser samt databaseadgange, og det først efter oprydningen.
- Kontrollér checkout, betalings-plugins og indlejrede scripts for ændringer.
Er der tegn på et dataudslip, løber GDPR's 72-timersfrist. Den juridiske vurdering foretager I sammen med jeres databeskyttelsesrådgiver og eventuelt jeres advokat.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer på afstand den faktiske PHP-pakkestatus, driftsformen (f.eks. mod_php eller PHP-FPM) og om alle workers er genstartet.
- Vi undersøger shopfiler, database og checkout for webshells, skimming-kode og nye admin-konti og fjerner fundet malware.
- Vi koordinerer med jeres bureau og jeres hostingudbyder, så shopvedligeholdelse og serverdrift ikke går hinanden forbi.
- Vi dokumenterer fund og foranstaltninger, så I kan forelægge dem for betalingsudbyder, forsikringsselskab og databeskyttelsesrådgiver.
- Derefter hærder vi serveren og overtager på ønske den løbende overvågning.
Ofte stillede spørgsmål
Skal jeg tage min shop af nettet på grund af PHP2Shell?
BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler midlertidigt at tage webservere af nettet, hvis PHP-opdateringen ikke kan gennemføres med det samme. For en shop er en vedligeholdelsestilstand med en informationsside ofte bedre end en fejlmeddelelse. Så snart PHP er patchet, og alle processer er genstartet, kan shoppen åbne igen.
Er kreditkortdata i min shop i fare?
I de fleste shops ligger kortdata ikke på den egen server, men hos betalingsudbyderen. Farligt er derimod manipuleret kode i checkout, som opsnapper indtastninger, før de når udbyderen. Derfor hører checkout med til enhver kontrol efter et angreb.
Er det nok at opdatere Shopware eller WooCommerce?
Nej. PHP2Shell berører selve PHP, ikke shopsystemet. En shopopdatering lukker ikke sårbarheden, og en PHP-rettelse fjerner ikke skadelig kode, der allerede er blevet indsmuglet.
Hvem skal jeg informere efter et dataudslip?
Ved personoplysninger kommer en anmeldelse til databeskyttelsestilsynet inden for 72 timer i betragtning, alt efter risikoen også underretning af de berørte. Hertil kommer kontraktlige forpligtelser over for betalingsudbyder og forsikringsselskab. Vurderingen i det enkelte tilfælde foretager I sammen med databeskyttelsesrådgiveren og en advokat.