Kort sagt: Den Shopware 6-sårbarhed, som mange forhandlere pt. søger efter, er i virkeligheden en sårbarhed i PHP. Shopware-opdateringer lukker den ikke. I har brug for et patchet PHP med genstart af alle processer og bør derefter kontrollere .env, custom/plugins, public-mappen og API-integrationerne.
Hvad PHP2Shell betyder for Shopware 6
Shopware 6 bygger på PHP-frameworket Symfony og kører oftest med PHP-FPM bag Nginx eller Apache. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 berører netop denne driftsform. Ifølge PHP-teamet gør de det muligt at køre skadelig kode på afstand, uden login i shoppen.
En angriber med kodekørsel på serveren når alt, hvad shoppen selv har adgang til: kundedata, ordrer, fakturadokumenter, adgangsdata til varelagersystemer og betalingsudbydere. Den tekniske baggrund forklarer vi under Hvad er PHP2Shell?.
Kontrollér Shopware 6-sårbarheden: hvilket PHP kører egentlig?
Shopware 6 vedligeholdes meget via kommandolinjen, f.eks. med bin/console. Her ligger en fejl lige for: php -v viser versionen af kommandolinje-PHP, ikke nødvendigvis den af PHP-FPM, som behandler shoppens forespørgsler. På mange servere er der flere PHP-versioner installeret parallelt.
Pålidelige er oplysningen i hostingpanelet for det konkrete domæne og hostingudbyderens bekræftelse af pakkestatus. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35; backports kan bære ældre numre. Hvilke PHP-versioner jeres Shopware-version understøtter, kontrollerer I ifølge systemkravene i dokumentationen på shopware.com. Hvordan I selv kan se efter, står under Kontrollér PHP-version og patch-status korrekt.
Ét punkt overses ofte ved Shopware 6: Mange shops behandler beskedkøen og planlagte opgaver via vedvarende kørende baggrundsprocesser, f.eks. bin/console messenger:consume under en proceshåndtering. Disse processer indlæser PHP én gang ved start. Efter opdateringen skal derfor ikke kun PHP-FPM, men også disse workers genstartes. Ellers arbejder en del af shoppen videre med det gamle, sårbare PHP i hukommelsen.
Mapper og filer, I bør kende
| Sted | Indhold | Hvorfor relevant |
|---|---|---|
.env, .env.local |
Databaseadgang, APP_SECRET, yderligere nøgler |
Fornyes ved mistanke |
public/ |
Dokumentrod med index.php, medier, tema-filer |
Ekstra PHP-filer er mistænkelige |
public/theme/ |
kompilerede JavaScript- og CSS-filer i storefront | Sted for indsmuglede skimmere |
custom/plugins/, custom/apps/ |
Udvidelser | Ændret plugin-kode |
files/ |
private filer som fakturaer og følgesedler | Personoplysninger |
var/log/ |
Shoppens logfiler | Sikre spor |
Ufarlige første kontroller:
# Vis installerede plugins med version og status
bin/console plugin:list
# List PHP-filer i den offentlige mappe
find public -type f -name "*.php"
# Vis kendte sårbarheder i Composer-afhængigheder
composer audit
I mappen public/ bør der kun ligge få, kendte PHP-filer. Alt ukendt bør sikres og undersøges, ikke slettes med det samme.
Kontrollér i administrationen under Indstillinger > System områderne "Brugere & rettigheder" og "Integrationer". Ukendte brugere eller API-integrationer er en bagdør, som enhver filscanning overser.
Admin-adgang, plugins og apps som risiko
Administrationen ligger som standard under /admin. Beskyt den med personlige konti, stærk login og, hvis muligt, med en adgangsbegrænsning til kendte netværk. Integrationer til varelager, markedspladser eller forsendelsesudbydere bør kun have de rettigheder, de virkelig har brug for.
Plugins fra storen og egenudviklinger medbringer egen PHP-kode, apps desuden webhooks til eksterne servere. Jo flere udvidelser, desto større angrebsflade og desto mere omstændelig hver PHP-opgradering. Fjern plugins, der ikke længere bruges, fuldstændigt.
Hvad en Shopware-opdatering kan, og hvad den ikke kan
En opdatering af Shopware eller et plugin lukker kendte fejl i denne kode. Den kan ikke:
- patche PHP på serveren,
- genstarte gamle PHP-FPM-processer,
- sikkert fjerne fremmede filer i
public/eller manipulerede tema-filer, - slette fremmede brugere eller integrationer,
- dokumentere, at der ikke er sket noget før rettelsen.
Efter en PHP-opdatering til en ny hovedversion bør I genskabe cache og tema og kontrollere shoppen i et testmiljø. PHP-skiftet med dokumentation overtager på ønske vores PHP-patch-service.
Shopware 6 kører hos større forhandlere ofte på flere app-servere. Så skal hver server være patchet og genstartet, også dem, der kun afvikler baggrundsopgaver. Driver en tjenesteudbyder shoppen som administreret platform, bør denne bekræfte status for alle noder over for jer.
Hvordan hjælper PHP SOS konkret?
- Vi fastslår, hvilket PHP jeres shop faktisk bruger via FPM, og afklarer rettelse og genstart med hostingudbyder eller bureau.
- Vi sikrer logs fra 20.10.2026, database og filer.
- Vi kontrollerer
public/, kompilerede tema-filer, plugins, brugere og integrationer for uregelmæssigheder. - Ved et fund renser vi shoppen sammen med jeres bureau og fornyer nøgler og adgange på en ordnet måde.
Ofte stillede spørgsmål
Er Shopware 6 selv berørt af PHP2Shell?
Sårbarhederne sidder i PHP, ikke i Shopware-koden. Enhver Shopware 6-shop på et upatchet PHP er derfor potentielt sårbar, uafhængigt af Shopware-versionen. En Shopware-opdatering ændrer ikke på det.
Hvilken fil i Shopware 6 er særligt kritisk efter et angreb?
Filen .env eller .env.local med databaseadgang og APP_SECRET. Den, der kunne læse den, kender jeres adgangsdata. Ved mistanke bør disse værdier fornyes i samråd med jeres bureau.
Hvad er integrationer i Shopware 6, og hvorfor skal de kontrolleres?
Integrationer er API-adgange for eksterne systemer som varelager- eller markedspladssystemer. En fremmed integration med administratorrettigheder giver fuld adgang til shoppen via API'et, uden at der ligger en fil på serveren.