# OXID eShop Sicherheit nach PHP2Shell: Shop und Schnittstellen absichern

> OXID eShop nach PHP2Shell absichern: PHP-Stand im Admin prüfen, config.inc.php und Module kontrollieren, Admin-Konten und B2B-Schnittstellen sichern.

Quelle: https://phpsos.de/plattformen/oxid-eshop/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Bei der OXID eShop Sicherheit geht es nach PHP2Shell zuerst um den Server: Die Lücke liegt in PHP, nicht in OXID. Lassen Sie den PHP-Stand bestätigen und alle Prozesse neu starten. Danach prüfen Sie `config.inc.php`, Module, Theme-Dateien, Admin-Konten und die Zugänge zu ERP und Zahlungsdiensten.

## Warum OXID-Shops genau hinsehen sollten

OXID eShop ist im deutschsprachigen Raum vor allem im B2B-Handel, bei Herstellern mit Direktvertrieb und im Großhandel verbreitet. Solche Shops sind selten Insellösungen: Sie tauschen Bestellungen, Preise, Bestände und Kundendaten mit ERP, PIM und Zahlungsdiensten aus. Ein Angreifer auf dem Shop-Server sieht deshalb oft mehr als nur den Shop.

Die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team Schadcode aus der Ferne ohne Anmeldung. Ob OXID selbst aktuell ist, spielt dafür keine Rolle. Typische Daten in OXID-Shops sind:

- Firmenkunden mit Ansprechpartnern, Adressen, Kundennummern und individuellen Preisen
- Bestellhistorie und Angebotsanfragen
- Zugangsdaten zu ERP, Zahlungs- und Versanddiensten in Konfiguration und Modul-Einstellungen
- Mitarbeiterkonten im Admin-Bereich

## OXID eShop Sicherheit: PHP-Stand richtig prüfen

Im Admin-Bereich zeigt **Service > Systeminfo** die PHP-Angaben des laufenden Shops. Das ist die Web-Version, mit der Kunden bedient werden. Die OXID-Konsole, Importe und Cronjobs laufen dagegen oft mit einem Kommandozeilen-PHP, das eine andere Version sein kann. Beide müssen gepatcht sein.

Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Distributionen und Hoster liefern Korrekturen teils als Backport aus, die Nummer bleibt dann gleich; entscheidend ist der bestätigte Paketstand. Welche PHP-Versionen Ihre OXID-Version unterstützt, prüfen Sie laut Systemanforderungen in der Dokumentation des Herstellers auf oxid-esales.com.

Ältere OXID-Shops der Generation 4 oder frühe Versionen der Generation 6 laufen häufig noch auf alten PHP-Versionen ohne offizielle Updates. Dann braucht es bis zum Upgrade Übergangsschutz und einen festen Zeitplan.

## Verzeichnisse und Dateien in OXID

Seit OXID 6 wird der Shop über Composer installiert; die Dokumentwurzel ist in der Regel das Verzeichnis `source/`.

| Ort | Inhalt | Prüfpunkt |
|---|---|---|
| `source/config.inc.php` | Datenbankzugang, Grundeinstellungen | eingeschobener Code, Passwort nach Verdacht ändern |
| `source/modules/` (bis OXID 6), ab OXID 7 `vendor/` | Module, teils aus Composer-Paketen | unbekannte Module, veränderte Dateien |
| `var/configuration/` | Modul- und Shop-Konfiguration als Dateien | unerwartete Änderungen |
| `source/out/` | Themes, Bilder, JavaScript | fremde Skripte, PHP-Dateien in Bildordnern |
| `source/tmp/` | kompilierte Templates und Cache | nach Bereinigung leeren |
| `source/log/` | Shop-Protokoll | vor Änderungen sichern |

Kompilierte Templates im `tmp`-Verzeichnis werden oft übersehen. Sie bestehen aus PHP-Code und werden nach einer Bereinigung neu erzeugt; deshalb sollte der Ordner nach jedem Fund geleert werden.

Ungefährliche erste Prüfungen:

```bash
# PHP-Dateien in Bild- und Medienordnern
find source/out -type f -name "*.php"
# Seit dem 17.10.2026 geänderte Moduldateien (OXID 6; ab OXID 7 liegen Module in vendor/)
find source/modules -type f -newermt "2026-10-17"
# Bekannte Lücken in Abhängigkeiten
composer audit
```

> **Wichtig:**
> Ein bereinigter Shop-Server macht abgeflossene Schnittstellen-Zugänge nicht wieder geheim. Erneuern Sie nach einem Verdacht die Zugangsdaten zu ERP, Zahlungs- und Versanddiensten in Absprache mit deren Betreibern.

## Admin-Bereich und Module

Der Admin-Bereich liegt standardmäßig unter `/admin/`. Prüfen Sie die Benutzerverwaltung auf Konten mit Admin-Rechten, die niemand zuordnen kann, und auf Zugänge ehemaliger Dienstleister. Schränken Sie den Admin-Zugriff wenn möglich auf das Firmennetz oder ein VPN ein; im B2B-Umfeld ist das meist gut machbar.

Module für Zahlungsarten, ERP-Anbindung, B2B-Funktionen wie Staffelpreise oder Freigabeprozesse sind in OXID-Shops oft individuell angepasst. Jedes Modul ist eigener PHP-Code, und angepasste Module bremsen PHP-Upgrades häufig aus. Halten Sie fest, welche Module aktiv sind, wer sie pflegt und ob es eine Version für die angestrebte PHP-Version gibt.

## Was ein OXID-Update kann und was nicht

Ein Update von OXID oder einem Modul schließt bekannte Fehler in diesem Code und kann neuere PHP-Versionen ermöglichen. Es patcht nicht PHP und startet weder PHP-FPM noch Hintergrundprozesse neu. Fremde Dateien in `source/out`, manipulierte Module, kompilierte Templates und neue Admin-Konten bleiben bestehen. Ob es Anzeichen für einen Angriff gibt, prüfen Sie mit [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/). Zur Lage im Mittelstand passt [IT-Sicherheit für Mittelstand und Industrie](https://phpsos.de/branchen/mittelstand-industrie/).

Viele OXID-Shops haben neben dem Live-System eine Staging-Umgebung auf demselben oder einem zweiten Server. Prüfen und patchen Sie diese ebenfalls, denn sie enthält oft eine Kopie der Kundendaten und ist für Angreifer genauso nützlich.

## Wie hilft PHP SOS konkret?

- Wir stellen Web- und CLI-PHP Ihres OXID-Servers fest und lassen Patch und Neustart bestätigen.
- Wir sichern Logs ab dem 20.10.2026, Dateien und Datenbank.
- Wir prüfen `config.inc.php`, Module, Themes, kompilierte Templates und Admin-Konten.
- Bei einem Verdacht koordinieren wir über unsere [Incident Response](https://phpsos.de/leistungen/incident-response/) die Bereinigung und das Erneuern der Schnittstellen-Zugänge mit Ihrer Agentur und Ihren ERP-Dienstleistern.


## Häufige Fragen

**Ist OXID eShop von PHP2Shell betroffen?**  
PHP2Shell ist keine OXID-Lücke, sondern eine Lücke in PHP. Jeder OXID-Shop auf einem ungepatchten PHP-Server ist daher potenziell angreifbar. Ein OXID-Update schließt die Lücke nicht.

**Wo sehe ich in OXID die PHP-Version?**  
Im Admin-Bereich unter Service > Systeminfo, dort werden die PHP-Angaben des laufenden Shops angezeigt. Ob ein Backport eingespielt ist, erkennen Sie daran nicht; das bestätigt Ihr Hoster oder Betreiber.

**Welche OXID-Datei enthält die Zugangsdaten?**  
Die Datei config.inc.php im Verzeichnis source. Sie enthält den Datenbankzugang. Nach einem Verdacht sollten Sie das Datenbankpasswort ändern und die Datei auf eingeschobenen Code prüfen.

**Müssen wir unsere ERP-Schnittstelle prüfen?**  
Ja. Hat ein Angreifer Code auf dem Shop-Server ausgeführt, kann er Zugangsdaten zu ERP, PIM oder Zahlungsdiensten gelesen haben. Diese Zugänge sollten nach einem Verdacht erneuert werden.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [OXID eSales](https://www.oxid-esales.com/)
- [Unterstützte PHP-Versionen](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)