# OXID eShop sikkerhed efter PHP2Shell: sådan sikrer I shop og grænseflader

> Sikr OXID eShop efter PHP2Shell: kontrollér PHP-status i admin, gennemgå config.inc.php og moduler, og beskyt admin-konti og B2B-grænseflader.

Kilde: https://phpsos.de/da/plattformen/oxid-eshop/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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:

```bash
# 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
```

> **Vigtigt:**
> 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?](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/). Til situationen i mellemstore virksomheder passer [IT-sikkerhed for mellemstore virksomheder og industri](https://phpsos.de/da/branchen/mittelstand-industrie/).

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](https://phpsos.de/da/leistungen/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.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [OXID eSales](https://www.oxid-esales.com/)
- [Understøttede PHP-versioner](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)