# OXID eShop-säkerhet efter PHP2Shell: skydda butik och gränssnitt > Skydda OXID eShop efter PHP2Shell: kontrollera PHP-status i admin, granska config.inc.php och moduler, säkra administratörskonton och B2B-gränssnitt. Källa: https://phpsos.de/sv/plattformen/oxid-eshop/ Aktualitet: 2026-10-25 Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6 **Kort sagt:** Vid OXID eShop-säkerhet handlar det efter PHP2Shell först om servern: sårbarheten finns i PHP, inte i OXID. Låt PHP-statusen bekräftas och alla processer startas om. Därefter kontrollerar ni `config.inc.php`, moduler, temafiler, administratörskonton och åtkomsterna till ERP och betaltjänster. ## Varför OXID-butiker bör granskas noga OXID eShop är i den tyskspråkiga regionen framför allt utbrett inom B2B-handel, hos tillverkare med direktförsäljning och inom grosshandel. Sådana butiker är sällan fristående lösningar: de utbyter beställningar, priser, lagersaldon och kunduppgifter med ERP, PIM och betaltjänster. En angripare på butiksservern ser därför ofta mer än bara butiken. PHP-sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod på distans utan inloggning. Om OXID självt är aktuellt spelar ingen roll för detta. Typiska data i OXID-butiker är: - företagskunder med kontaktpersoner, adresser, kundnummer och individuella priser - orderhistorik och offertförfrågningar - åtkomstuppgifter till ERP, betal- och fraktjänster i konfiguration och modulinställningar - medarbetarkonton i administrationsområdet ## OXID eShop-säkerhet: kontrollera PHP-statusen på rätt sätt I administrationsområdet visar **Service > Systeminfo** PHP-uppgifterna för den körande butiken. Det är webbversionen, med vilken kunderna betjänas. OXID-konsolen, importer och cronjobb körs däremot ofta med ett kommandoradens PHP, som kan vara en annan version. Båda måste vara patchade. Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Distributioner och webbhotell levererar ibland rättningar som backport, och numret förblir då detsamma; avgörande är den bekräftade paketstatusen. Vilka PHP-versioner er OXID-version stöder kontrollerar ni enligt systemkraven i tillverkarens dokumentation på oxid-esales.com. Äldre OXID-butiker av generation 4 eller tidiga versioner av generation 6 körs ofta fortfarande på gamla PHP-versioner utan officiella uppdateringar. Då behövs fram till uppgraderingen ett tillfälligt skydd och en fast tidsplan. ## Kataloger och filer i OXID Sedan OXID 6 installeras butiken via Composer; dokumentroten är i regel katalogen `source/`. | Plats | Innehåll | Kontrollpunkt | |---|---|---| | `source/config.inc.php` | Databasåtkomst, grundinställningar | inskjuten kod, byt lösenord vid misstanke | | `source/modules/` (till och med OXID 6), från OXID 7 `vendor/` | Moduler, delvis från Composer-paket | okända moduler, ändrade filer | | `var/configuration/` | Modul- och butikskonfiguration som filer | oväntade ändringar | | `source/out/` | Teman, bilder, JavaScript | främmande skript, PHP-filer i bildmappar | | `source/tmp/` | kompilerade mallar och cache | töm efter sanering | | `source/log/` | Butikens logg | säkra före ändringar | Kompilerade mallar i katalogen `tmp` förbises ofta. De består av PHP-kod och byggs om efter en sanering; därför bör mappen tömmas efter varje fynd. Ofarliga första kontroller: ```bash # PHP-filer i bild- och mediamappar find source/out -type f -name "*.php" # Modulfiler som ändrats sedan den 17 oktober 2026 (OXID 6; från OXID 7 ligger moduler i vendor/) find source/modules -type f -newermt "2026-10-17" # Kända sårbarheter i beroenden composer audit ``` > **Viktigt:** > En sanerad butiksserver gör inte läckta gränssnittsåtkomster hemliga igen. Förnya vid misstanke åtkomstuppgifterna till ERP, betal- och fraktjänster i samråd med deras driftansvariga. ## Administrationsområde och moduler Administrationsområdet ligger som standard under `/admin/`. Kontrollera användarhanteringen med avseende på konton med administratörsrättigheter som ingen kan knyta till någon, och på åtkomster som tillhör tidigare tjänsteleverantörer. Begränsa administratörsåtkomsten om möjligt till företagsnätet eller ett VPN; i B2B-miljö är det oftast fullt genomförbart. Moduler för betalsätt, ERP-koppling och B2B-funktioner som mängdrabatter eller godkännandeprocesser är i OXID-butiker ofta individuellt anpassade. Varje modul är egen PHP-kod, och anpassade moduler bromsar ofta PHP-uppgraderingar. Anteckna vilka moduler som är aktiva, vem som underhåller dem och om det finns en version för den eftersträvade PHP-versionen. ## Vad en OXID-uppdatering klarar och inte klarar En uppdatering av OXID eller en modul stänger kända fel i den koden och kan möjliggöra nyare PHP-versioner. Den patchar inte PHP och startar varken om PHP-FPM eller bakgrundsprocesser. Främmande filer i `source/out`, manipulerade moduler, kompilerade mallar och nya administratörskonton blir kvar. Om det finns tecken på en attack kontrollerar ni med [Är jag redan komprometterad?](https://phpsos.de/sv/php2shell/bin-ich-gehackt-anzeichen/). Till läget i medelstora företag passar [IT-säkerhet för medelstora företag och industri](https://phpsos.de/sv/branchen/mittelstand-industrie/). Många OXID-butiker har vid sidan av livesystemet en staging-miljö på samma eller en andra server. Kontrollera och patcha även den, eftersom den ofta innehåller en kopia av kunddata och är lika användbar för angripare. ## Hur hjälper PHP SOS konkret? - Vi fastställer webb- och CLI-PHP på er OXID-server och låter patch och omstart bekräftas. - Vi säkrar loggar från och med den 20 oktober 2026, filer och databas. - Vi kontrollerar `config.inc.php`, moduler, teman, kompilerade mallar och administratörskonton. - Vid misstanke samordnar vi genom vår [incidenthantering](https://phpsos.de/sv/leistungen/incident-response/) saneringen och förnyandet av gränssnittsåtkomsterna med er byrå och era ERP-leverantörer. ## Vanliga frågor **Berörs OXID eShop av PHP2Shell?** PHP2Shell är ingen OXID-sårbarhet utan en sårbarhet i PHP. Varje OXID-butik på en server med opatchat PHP kan därför vara sårbar. En OXID-uppdatering stänger inte sårbarheten. **Var ser jag PHP-versionen i OXID?** I administrationsområdet under Service > Systeminfo visas PHP-uppgifterna för den körande butiken. Om en backport är installerad framgår inte av det; det bekräftar ert webbhotell eller er driftleverantör. **Vilken OXID-fil innehåller åtkomstuppgifterna?** Filen config.inc.php i katalogen source. Den innehåller databasåtkomsten. Vid misstanke bör ni byta databaslösenordet och kontrollera filen med avseende på inskjuten kod. **Måste vi kontrollera vårt ERP-gränssnitt?** Ja. Har en angripare kört kod på butiksservern kan denne ha läst åtkomstuppgifter till ERP, PIM eller betaltjänster. Dessa åtkomster bör förnyas vid misstanke. ## Källor - [php.net: säkerhetsmeddelanden](https://www.php.net/) - [OXID eSales](https://www.oxid-esales.com/) - [PHP-versioner som stöds](https://www.php.net/supported-versions.php) - [BSI](https://www.bsi.bund.de/)