Kort sagt: Är er webbutik hackad eller körs den på en ej patchad PHP-version handlar det om tre saker på en gång: kunduppgifter, kassan och er försäljning. Sätt butiken kontrollerat i underhållsläge, säkra loggar från och med den 20 oktober 2026 och klargör vem som uppdaterar och startar om PHP på er server.
Vad som står på spel i en webbutik
En butik är mer än en webbplats. Den hanterar kundkonton med lösenordshashar, leverans- och fakturaadresser, orderhistorik, kuponger och ofta även gränssnitt mot affärssystem, fraktbolag och marknadsplatser. Den som kan köra kod på servern kommer i regel åt databasen och de API-nycklar som finns lagrade där.
Kortuppgifter ligger oftast inte hos er utan hos betalningsleverantören. Det lugnar bara delvis: En angripare kan föra in JavaScript i beställningsflödet som läser med inmatningarna i webbläsaren. Sådana skimmingskript syns knappt i butiksdriften, eftersom beställningarna går igenom som vanligt.
Dessutom finns gränssnitten. En butik som lämnar över beställningar till affärssystem, fraktbolag och marknadsplatser lagrar åtkomstnycklarna för dem oftast i konfigurationsfiler på servern. Den som kopierar dem kan i handlarens namn skapa fraktetiketter, ändra lagersaldon eller missbruka marknadsplatskonton.
Typiska butikssystem och varför PHP2Shell drabbar dem
De utbredda butikssystemen bland medelstora företag körs på PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop och många äldre Shopware 5-installationer. PHP2Shell (CVE-2026-109618 och CVE-2026-109619, vardera CVSS 9,2) finns i PHP självt. Angripare behöver varken kundkonto eller adminåtkomst.
För handlare betyder det: Den senaste butiksuppdateringen skyddar inte. Avgörande är om PHP på servern ligger på 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller om webbhotellet har installerat en backport, och om alla PHP-processer har startats om därefter. För gamla butiker på PHP 8.1 eller äldre finns inga officiella uppdateringar från PHP-projektet längre. Då väntar vid sidan av nödläget en migrering som ni inte vill göra under tidspress i högsäsong.
Hackad webbutik: vad en incident konkret innebär
En komprometterad butik orsakar skada på flera nivåer som förstärker varandra:
- Försäljning: Varje timme i underhållsläge kostar beställningar. En butik som oupptäckt fortsätter köra kan dock bli betydligt dyrare.
- Kunduppgifter: Läckta adresser och beställningar används för riktade nätfiskemejl som verkar äkta eftersom de nämner verkliga beställningar.
- Synlighet: Upptäcker Google skadlig kod visas en varning i sökresultaten. Hur ni blir av med den framgår av guiden Ta bort Google-varning.
- Partner: Betalningsleverantörer och marknadsplatser har egna regler för säkerhetsincidenter. Den som anmäler för sent riskerar problem vid avräkningen.
Vem ansvarar: byrå, webbhotell eller handlare?
I många butiker faller frågan om PHP mellan stolarna. Byrån har byggt butiken och sköter pluginerna, webbhotellet driver servern, och handlaren utgår från att någon av dem tar hand om det. Vid managed hosting patchar oftast webbhotellet, vid en egen vServer ingen automatiskt.
| Uppgift | Vanligtvis ansvarig | Kontrollera |
|---|---|---|
| Uppdatera PHP-paketet | Webbhotell eller serverförvaltare | Skriftlig bekräftelse med paketstatus |
| Starta om PHP-processer | den som förvaltar servern | Tidpunkt för omstarten |
| Butik och plugin | Byrå | Underhållsavtal och åtkomster |
| Informera betalningsleverantör | Handlare | Avtalsenliga anmälningsskyldigheter |
En PHP-patch bevisar inte att inget har hänt tidigare. Om butiken angreps mellan den 17 oktober och patchtidpunkten kan inskickad kod fortsätta köra. Låt kontrollera det innan ni ger klartecken.
De första timmarna: ordningsföljd för handlare
- Sätt butiken i underhållsläge eller, om det inte går, ta den tillfälligt offline.
- Säkra webbserver-, PHP- och butikloggar från och med den 20 oktober 2026 innan rotation raderar dem.
- Be webbhotellet skriftligen bekräfta PHP-paketets status och omstarten.
- Förnya adminlösenord, API-nycklar för betalning, frakt och marknadsplatser samt databasåtkomster, och gör det först efter rensningen.
- Kontrollera kassan, betalningspluginerna och inbäddade skript efter ändringar.
Finns det tecken på ett dataläckage löper 72-timmarsfristen enligt GDPR. Den juridiska bedömningen gör ni med ert dataskyddsombud och vid behov er jurist.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar på distans den faktiska PHP-paketstatusen, driftläget (till exempel mod_php eller PHP-FPM) och om alla workers har startats om.
- Vi undersöker butikens filer, databas och kassa efter webshells, skimmingkod och nya adminkonton och tar bort funnen skadlig programvara.
- Vi samordnar med er byrå och ert webbhotell så att butiksunderhåll och serverdrift inte går förbi varandra.
- Vi dokumenterar fynd och åtgärder så att ni kan lägga fram dem för betalningsleverantör, försäkringsgivare och dataskyddsombud.
- Därefter härdar vi servern och tar på begäran över den löpande övervakningen.
Vanliga frågor
Måste jag ta butiken offline på grund av PHP2Shell?
BSI rekommenderar att webbservrar tillfälligt tas offline om PHP-uppdateringen inte kan göras direkt. För en butik är ett underhållsläge med informationssida ofta ett bättre sätt än ett felmeddelande. Så snart PHP är patchad och alla processer har startats om kan butiken öppna igen.
Är kreditkortsuppgifter i min butik i fara?
I de flesta butiker ligger kortuppgifter inte på den egna servern utan hos betalningsleverantören. Farlig är dock manipulerad kod i kassan som snappar upp inmatningar innan de når leverantören. Därför ingår kassan i varje granskning efter ett angrepp.
Räcker det att uppdatera Shopware eller WooCommerce?
Nej. PHP2Shell berör PHP självt, inte butikssystemet. En butiksuppdatering stänger inte sårbarheten, och en PHP-patch tar inte bort skadlig kod som redan har förts in.
Vem måste jag informera efter ett dataläckage?
Vid personuppgifter kan en anmälan till dataskyddsmyndigheten inom 72 timmar komma i fråga, och beroende på risken även information till de berörda. Dessutom finns avtalsenliga skyldigheter gentemot betalningsleverantör och försäkringsgivare. Bedömningen i det enskilda fallet gör ni med dataskyddsombud och jurist.