# OXID eShop beveiliging na PHP2Shell: webshop en koppelingen beveiligen

> OXID eShop na PHP2Shell beveiligen: PHP-status in de admin controleren, config.inc.php en modules nalopen, adminaccounts en B2B-koppelingen beveiligen.

Bron: https://phpsos.de/nl/plattformen/oxid-eshop/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Bij OXID eShop beveiliging gaat het na PHP2Shell eerst om de server: de kwetsbaarheid zit in PHP, niet in OXID. Laat de PHP-status bevestigen en alle processen herstarten. Controleer daarna `config.inc.php`, modules, themabestanden, adminaccounts en de toegangen tot ERP en betaaldiensten.

## Waarom OXID-webshops goed moeten kijken

OXID eShop is in het Duitse taalgebied vooral verbreid in de B2B-handel, bij fabrikanten met directe verkoop en in de groothandel. Zulke webshops zijn zelden eilandoplossingen: ze wisselen bestellingen, prijzen, voorraden en klantgegevens uit met ERP, PIM en betaaldiensten. Een aanvaller op de webshopserver ziet daarom vaak meer dan alleen de webshop.

De PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om op afstand en zonder inloggen schadelijke code uit te voeren. Of OXID zelf actueel is, speelt daarbij geen rol. Typische gegevens in OXID-webshops zijn:

- zakelijke klanten met contactpersonen, adressen, klantnummers en individuele prijzen
- bestelgeschiedenis en offerteaanvragen
- toegangsgegevens tot ERP, betaal- en verzenddiensten in configuratie en module-instellingen
- medewerkersaccounts in het admin-gedeelte

## OXID eShop beveiliging: de PHP-status goed controleren

In het admin-gedeelte toont **Service > Systeeminfo** de PHP-gegevens van de draaiende webshop. Dat is de webversie waarmee klanten worden bediend. De OXID-console, imports en cronjobs draaien daarentegen vaak met een opdrachtregel-PHP, die een andere versie kan zijn. Beide moeten zijn gepatcht.

Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Distributies en hostingproviders leveren correcties soms als backport uit, het nummer blijft dan gelijk; bepalend is de bevestigde pakketstatus. Welke PHP-versies uw OXID-versie ondersteunt, controleert u volgens de systeemeisen in de documentatie van de fabrikant op oxid-esales.com.

Oudere OXID-webshops van generatie 4 of vroege versies van generatie 6 draaien vaak nog op oude PHP-versies zonder officiële updates. Dan zijn tot de upgrade tijdelijke bescherming en een vast tijdschema nodig.

## Mappen en bestanden in OXID

Sinds OXID 6 wordt de webshop via Composer geïnstalleerd; de documentroot is doorgaans de map `source/`.

| Plek | Inhoud | Controlepunt |
|---|---|---|
| `source/config.inc.php` | Databasetoegang, basisinstellingen | ingevoegde code, wachtwoord bij vermoeden wijzigen |
| `source/modules/` (tot OXID 6), vanaf OXID 7 `vendor/` | Modules, deels uit Composer-pakketten | onbekende modules, gewijzigde bestanden |
| `var/configuration/` | Module- en webshopconfiguratie als bestanden | onverwachte wijzigingen |
| `source/out/` | Thema's, afbeeldingen, JavaScript | vreemde scripts, PHP-bestanden in afbeeldingsmappen |
| `source/tmp/` | gecompileerde templates en cache | na reiniging legen |
| `source/log/` | Webshoplog | vóór wijzigingen veiligstellen |

Gecompileerde templates in de map `tmp` worden vaak over het hoofd gezien. Ze bestaan uit PHP-code en worden na een reiniging opnieuw gegenereerd; daarom moet de map na elke vondst worden geleegd.

Ongevaarlijke eerste controles:

```bash
# PHP-bestanden in afbeeldings- en mediamappen
find source/out -type f -name "*.php"
# Sinds 17-10-2026 gewijzigde modulebestanden (OXID 6; vanaf OXID 7 staan modules in vendor/)
find source/modules -type f -newermt "2026-10-17"
# Bekende kwetsbaarheden in afhankelijkheden
composer audit
```

> **Belangrijk:**
> Een gereinigde webshopserver maakt weggelekte koppelingstoegangen niet weer geheim. Vernieuw bij een vermoeden de toegangsgegevens tot ERP, betaal- en verzenddiensten in overleg met hun beheerders.

## Admin-gedeelte en modules

Het admin-gedeelte staat standaard onder `/admin/`. Controleer het gebruikersbeheer op accounts met adminrechten die niemand kan plaatsen en op toegangen van voormalige dienstverleners. Beperk de admintoegang zo mogelijk tot het bedrijfsnetwerk of een VPN; in een B2B-omgeving is dat meestal goed te doen.

Modules voor betaalmethoden, ERP-koppeling en B2B-functies zoals staffelprijzen of goedkeuringsprocessen zijn in OXID-webshops vaak individueel aangepast. Elke module is eigen PHP-code, en aangepaste modules remmen PHP-upgrades vaak af. Leg vast welke modules actief zijn, wie ze onderhoudt en of er een versie bestaat voor de beoogde PHP-versie.

## Wat een OXID-update wel en niet kan

Een update van OXID of een module dicht bekende fouten in die code en kan nieuwere PHP-versies mogelijk maken. Ze patcht PHP niet en herstart noch PHP-FPM noch achtergrondprocessen. Vreemde bestanden in `source/out`, gemanipuleerde modules, gecompileerde templates en nieuwe adminaccounts blijven bestaan. Of er aanwijzingen voor een aanval zijn, controleert u met [Ben ik al gecompromitteerd?](https://phpsos.de/nl/php2shell/bin-ich-gehackt-anzeichen/). Bij de situatie in het mkb past [IT-beveiliging voor mkb en industrie](https://phpsos.de/nl/branchen/mittelstand-industrie/).

Veel OXID-webshops hebben naast het live-systeem een stagingomgeving op dezelfde of een tweede server. Controleer en patch die eveneens, want ze bevat vaak een kopie van de klantgegevens en is voor aanvallers net zo nuttig.

## Hoe helpt PHP SOS concreet?

- Wij stellen de web- en CLI-PHP van uw OXID-server vast en laten patch en herstart bevestigen.
- Wij maken een kopie van logs vanaf 20-10-2026, bestanden en database.
- Wij controleren `config.inc.php`, modules, thema's, gecompileerde templates en adminaccounts.
- Bij een vermoeden coördineren wij via onze [incident response](https://phpsos.de/nl/leistungen/incident-response/) de reiniging en het vernieuwen van de koppelingstoegangen met uw bureau en uw ERP-dienstverleners.


## Veelgestelde vragen

**Is OXID eShop getroffen door PHP2Shell?**  
PHP2Shell is geen OXID-kwetsbaarheid, maar een kwetsbaarheid in PHP. Elke OXID-webshop op een ongepatchte PHP-server is daarom potentieel kwetsbaar. Een OXID-update sluit de kwetsbaarheid niet.

**Waar zie ik in OXID de PHP-versie?**  
In het admin-gedeelte onder Service > Systeeminfo, waar de PHP-gegevens van de draaiende webshop worden getoond. Of er een backport is doorgevoerd, herkent u daaraan niet; dat bevestigt uw hostingprovider of beheerder.

**Welk OXID-bestand bevat de toegangsgegevens?**  
Het bestand config.inc.php in de map source. Het bevat de databasetoegang. Wijzig bij een vermoeden het databasewachtwoord en controleer het bestand op ingevoegde code.

**Moeten wij onze ERP-koppeling controleren?**  
Ja. Heeft een aanvaller code op de webshopserver uitgevoerd, dan kan hij toegangsgegevens tot ERP, PIM of betaaldiensten hebben gelezen. Deze toegangen moeten bij een vermoeden worden vernieuwd.

## Bronnen

- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [OXID eSales](https://www.oxid-esales.com/)
- [Ondersteunde PHP-versies](https://www.php.net/supported-versions.php)
- [BSI (Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/)
