Kort sagt: Den Shopware 6-sårbarhet som många handlare söker efter just nu är i själva verket en sårbarhet i PHP. Shopware-uppdateringar stänger den inte. Ni behöver ett patchat PHP med omstart av alla processer och bör därefter kontrollera .env, custom/plugins, katalogen public och API-integrationerna.
Vad PHP2Shell betyder för Shopware 6
Shopware 6 bygger på PHP-ramverket Symfony och körs oftast med PHP-FPM bakom Nginx eller Apache. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 berör just detta driftläge. Enligt PHP-teamet gör de det möjligt att köra skadlig kod på distans, utan inloggning i butiken.
En angripare med kodkörning på servern når allt som butiken själv har åtkomst till: kunduppgifter, beställningar, fakturadokument samt åtkomstuppgifter till affärssystem och betalleverantörer. Den tekniska bakgrunden förklarar vi under Vad är PHP2Shell?.
Kontrollera Shopware 6-sårbarheten: vilket PHP körs egentligen?
Shopware 6 sköts till stor del via kommandoraden, till exempel med bin/console. Då ligger ett misstag nära: php -v visar versionen av kommandoradens PHP, inte nödvändigtvis den som PHP-FPM använder för butikens förfrågningar. På många servrar är flera PHP-versioner installerade parallellt.
Tillförlitliga är uppgiften i hostingpanelen för den aktuella domänen och webbhotellets bekräftelse av paketstatus. Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35; backports kan bära äldre nummer. Vilka PHP-versioner er Shopware-version stöder kontrollerar ni enligt systemkraven i dokumentationen på shopware.com. Hur ni kontrollerar själva står under Kontrollera PHP-version och patchstatus på rätt sätt.
En punkt förbises ofta hos Shopware 6: många butiker hanterar meddelandekön och schemalagda uppgifter via ständigt körande bakgrundsprocesser, till exempel bin/console messenger:consume under en processhanterare. Dessa processer laddar PHP en gång vid start. Efter uppdateringen måste därför inte bara PHP-FPM utan även dessa workers startas om. Annars fortsätter en del av butiken att arbeta med det gamla, sårbara PHP i minnet.
Kataloger och filer som ni bör känna till
| Plats | Innehåll | Varför relevant |
|---|---|---|
.env, .env.local |
Databasåtkomst, APP_SECRET, fler nycklar |
Förnya vid misstanke |
public/ |
Dokumentrot med index.php, media, temafiler |
Ytterligare PHP-filer är misstänkta |
public/theme/ |
kompilerade JavaScript- och CSS-filer för Storefront | Plats för insmugglade skimmers |
custom/plugins/, custom/apps/ |
Tillägg | Ändrad plugin-kod |
files/ |
privata filer som fakturor och följesedlar | Personuppgifter |
var/log/ |
Butikens loggar | Säkra spåren |
Ofarliga första kontroller:
# Visa installerade plugin med version och status
bin/console plugin:list
# Lista PHP-filer i den publika katalogen
find public -type f -name "*.php"
# Visa kända sårbarheter i Composer-beroenden
composer audit
I mappen public/ ska bara några få, kända PHP-filer ligga. Allt okänt ska säkras och undersökas, inte raderas direkt.
Kontrollera i administrationen under Inställningar > System områdena ”Användare & behörigheter” och ”Integrationer”. Okända användare eller API-integrationer är en bakdörr som varje filskanning missar.
Administratörsåtkomst, plugin och appar som risk
Administrationen ligger som standard under /admin. Skydda den med personliga konton, stark inloggning och, om möjligt, en åtkomstbegränsning till kända nät. Integrationer för affärssystem, marknadsplatser eller fraktleverantörer bör bara ha de rättigheter de verkligen behöver.
Plugin från butiken och egenutvecklingar har egen PHP-kod, appar dessutom webhooks till externa servrar. Ju fler tillägg, desto större angreppsyta och desto mer arbetskrävande blir varje PHP-uppgradering. Ta bort plugin som inte längre används helt och hållet.
Vad en Shopware-uppdatering klarar och inte klarar
En uppdatering av Shopware eller ett plugin stänger kända fel i den koden. Den kan inte:
- patcha PHP på servern,
- starta om gamla PHP-FPM-processer,
- på ett säkert sätt ta bort främmande filer i
public/eller manipulerade temafiler, - radera främmande användare eller integrationer,
- bevisa att inget har hänt före patchen.
Efter en PHP-uppdatering till en ny huvudversion bör ni bygga om cache och tema och testa butiken i en testmiljö. Själva PHP-bytet med verifiering tar på begäran vår PHP-patchtjänst hand om.
Hos större handlare körs Shopware 6 ofta på flera appservrar. Då måste varje server vara patchad och omstartad, även sådana som bara hanterar bakgrundsuppgifter. Om en tjänsteleverantör driver butiken som hanterad plattform bör denne bekräfta statusen för alla noder.
Hur hjälper PHP SOS konkret?
- Vi fastställer vilket PHP er butik faktiskt använder via FPM och reder ut patch och omstart med webbhotell eller byrå.
- Vi säkrar loggar från och med den 20 oktober 2026, databas och filer.
- Vi kontrollerar
public/, kompilerade temafiler, plugin, användare och integrationer med avseende på avvikelser. - Vid ett fynd saneras butiken tillsammans med er byrå och nycklar och åtkomster förnyas på ett ordnat sätt.
Vanliga frågor
Berörs Shopware 6 självt av PHP2Shell?
Sårbarheterna finns i PHP, inte i Shopware-koden. Varje Shopware 6-butik på ett opatchat PHP kan därför vara sårbar, oavsett Shopware-version. En Shopware-uppdatering ändrar ingenting i det.
Vilken fil i Shopware 6 är särskilt kritisk efter en attack?
Filen .env eller .env.local med databasåtkomst och APP_SECRET. Den som kunde läsa den känner till era åtkomstuppgifter. Vid misstanke bör dessa värden förnyas, i samråd med er byrå.
Vad är integrationer i Shopware 6 och varför ska de kontrolleras?
Integrationer är API-åtkomster för externa system som affärssystem eller marknadsplatser. En främmande integration med administratörsbehörighet ger full åtkomst till butiken via API:et utan att någon fil ligger på servern.