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:
# 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
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?. Till läget i medelstora företag passar IT-säkerhet för medelstora företag och industri.
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 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.