Kort sagt: Ved OXID eShop sikkerhed handler det efter PHP2Shell først om serveren: Sårbarheden ligger i PHP, ikke i OXID. Lad PHP-status bekræfte og alle processer genstarte. Derefter kontrollerer I config.inc.php, moduler, tema-filer, admin-konti og adgangene til ERP og betalingstjenester.
Hvorfor OXID-shops bør undersøges nøje
OXID eShop er i det tysksprogede område især udbredt i B2B-handel, hos producenter med direkte salg og i engroshandel. Sådanne shops er sjældent isolerede løsninger: De udveksler ordrer, priser, lagerbeholdninger og kundedata med ERP, PIM og betalingstjenester. En angriber på shopserveren ser derfor ofte mere end blot shoppen.
PHP-sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode på afstand uden login. Om OXID selv er opdateret, spiller ingen rolle for det. Typiske data i OXID-shops er:
- Erhvervskunder med kontaktpersoner, adresser, kundenumre og individuelle priser
- Ordrehistorik og tilbudsforespørgsler
- Adgangsdata til ERP, betalings- og forsendelsestjenester i konfiguration og modulindstillinger
- Medarbejderkonti i admin-området
OXID eShop sikkerhed: kontrollér PHP-status korrekt
I admin-området viser Service > Systeminfo PHP-oplysningerne for den kørende shop. Det er den web-version, som kunderne betjenes med. OXID-konsollen, importer og cronjobs kører derimod ofte med et kommandolinje-PHP, som kan være en anden version. Begge skal være patchet.
Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Distributioner og hostingudbydere leverer nogle gange rettelser som backport, nummeret forbliver så det samme; afgørende er den bekræftede pakkestatus. Hvilke PHP-versioner jeres OXID-version understøtter, kontrollerer I ifølge systemkravene i producentens dokumentation på oxid-esales.com.
Ældre OXID-shops af generation 4 eller tidlige versioner af generation 6 kører ofte stadig på gamle PHP-versioner uden officielle opdateringer. Så er der brug for midlertidig beskyttelse og en fast tidsplan indtil opgraderingen.
Mapper og filer i OXID
Siden OXID 6 installeres shoppen via Composer; dokumentroden er som regel mappen source/.
| Sted | Indhold | Kontrolpunkt |
|---|---|---|
source/config.inc.php |
Databaseadgang, grundindstillinger | indskudt kode, skift adgangskode ved mistanke |
source/modules/ (til og med OXID 6), fra OXID 7 vendor/ |
Moduler, delvist fra Composer-pakker | ukendte moduler, ændrede filer |
var/configuration/ |
Modul- og shopkonfiguration som filer | uventede ændringer |
source/out/ |
Temaer, billeder, JavaScript | fremmede scripts, PHP-filer i billedmapper |
source/tmp/ |
kompilerede skabeloner og cache | tøm efter oprydning |
source/log/ |
Shoppens log | sikres før ændringer |
Kompilerede skabeloner i tmp-mappen overses ofte. De består af PHP-kode og genskabes efter en oprydning; derfor bør mappen tømmes efter hvert fund.
Ufarlige første kontroller:
# PHP-filer i billed- og medie-mapper
find source/out -type f -name "*.php"
# Modulfiler ændret siden 17.10.2026 (OXID 6; fra OXID 7 ligger moduler i vendor/)
find source/modules -type f -newermt "2026-10-17"
# Kendte sårbarheder i afhængigheder
composer audit
En renset shopserver gør ikke udsivede grænsefladeadgange hemmelige igen. Forny ved mistanke adgangsdata til ERP, betalings- og forsendelsestjenester i samråd med deres driftsansvarlige.
Admin-området og moduler
Admin-området ligger som standard under /admin/. Kontrollér brugeradministrationen for konti med admin-rettigheder, som ingen kan placere, og for adgange tilhørende tidligere tjenesteudbydere. Begræns om muligt admin-adgangen til virksomhedens netværk eller et VPN; i B2B-miljøer er det som regel let at gennemføre.
Moduler til betalingsmetoder, ERP-integration og B2B-funktioner som mængderabatter eller godkendelsesprocesser er i OXID-shops ofte tilpasset individuelt. Hvert modul er egen PHP-kode, og tilpassede moduler bremser ofte PHP-opgraderinger. Notér, hvilke moduler der er aktive, hvem der vedligeholder dem, og om der findes en version til den tilsigtede PHP-version.
Hvad en OXID-opdatering kan, og hvad den ikke kan
En opdatering af OXID eller et modul lukker kendte fejl i denne kode og kan gøre nyere PHP-versioner mulige. Den patcher ikke PHP og genstarter hverken PHP-FPM eller baggrundsprocesser. Fremmede filer i source/out, manipulerede moduler, kompilerede skabeloner og nye admin-konti forbliver. Om der er tegn på et angreb, kontrollerer I med Er jeg allerede kompromitteret?. Til situationen i mellemstore virksomheder passer IT-sikkerhed for mellemstore virksomheder og industri.
Mange OXID-shops har ud over live-systemet et staging-miljø på den samme eller en anden server. Kontrollér og patch også dette, for det indeholder ofte en kopi af kundedata og er lige så nyttigt for angribere.
Hvordan hjælper PHP SOS konkret?
- Vi fastslår web- og CLI-PHP på jeres OXID-server og lader rettelse og genstart bekræfte.
- Vi sikrer logs fra 20.10.2026, filer og database.
- Vi kontrollerer
config.inc.php, moduler, temaer, kompilerede skabeloner og admin-konti. - Ved mistanke koordinerer vi via vores incident response oprydningen og fornyelsen af grænsefladeadgangene med jeres bureau og jeres ERP-leverandører.
Ofte stillede spørgsmål
Er OXID eShop berørt af PHP2Shell?
PHP2Shell er ikke en OXID-sårbarhed, men en sårbarhed i PHP. Enhver OXID-shop på en upatchet PHP-server er derfor potentielt sårbar. En OXID-opdatering lukker ikke sårbarheden.
Hvor ser jeg PHP-versionen i OXID?
I admin-området under Service > Systeminfo vises PHP-oplysningerne for den kørende shop. Om en backport er indspillet, kan I ikke se heraf; det bekræfter jeres hostingudbyder eller driftsleverandør.
Hvilken OXID-fil indeholder adgangsdata?
Filen config.inc.php i mappen source. Den indeholder databaseadgangen. Ved mistanke bør I ændre databaseadgangskoden og kontrollere filen for indskudt kode.
Skal vi kontrollere vores ERP-grænseflade?
Ja. Har en angriber kørt kode på shopserveren, kan vedkommende have læst adgangsdata til ERP, PIM eller betalingstjenester. Disse adgange bør fornyes ved mistanke.