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:
# 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
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?. Zur Lage im Mittelstand passt IT-Sicherheit für Mittelstand und 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 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.