KI erleichtert automatisierte Cyberangriffe und schafft zugleich neue Risiken durch Bots, Scraper und unkontrollierte Agenten. Warum OXID-Shopbetreiber ihre bisherige Sicherheitsstrategie jetzt neu bewerten sollten.
In meinen inzwischen 20 Jahren als E-Commerce-Unternehmer habe ich zahlreiche Onlineshops, Plattformen und technische Entwicklungen begleitet. Seit mehr als 13 Jahren beschäftige ich mich intensiv mit OXID eShop.
Dabei hatte OXID aus meiner Sicht lange einen besonderen Vorteil: Die Plattform war im Vergleich zu weltweit stark verbreiteten Systemen ein weniger attraktives Ziel für breit angelegte Cyberangriffe.
Das soll keineswegs bedeuten, dass OXID eShop grundsätzlich sicherer als andere Systeme war oder keine Sicherheitslücken kannte. Vielmehr war der wirtschaftliche Anreiz für Angreifer häufig geringer. Wer Angriffswerkzeuge entwickelte, konzentrierte sich bevorzugt auf Plattformen, bei denen sich dieselbe Schwachstelle auf eine möglichst große Zahl von Installationen anwenden ließ.
Mit künstlicher Intelligenz verändert sich diese Rechnung.
KI kann technische Informationen schneller auswerten, Programmcode erstellen und verändern, potenzielle Ziele automatisiert untersuchen und unterschiedliche Angriffsmethoden in kurzer Zeit anpassen. Dadurch werden auch weniger verbreitete Anwendungen für Angreifer interessanter.
Nicht weil OXID plötzlich weiter verbreitet wäre, sondern weil der Aufwand sinkt, auch kleinere Plattformen systematisch zu untersuchen und anzugreifen.
Eine geringe Verbreitung ist kein verlässlicher Schutz mehr
Cyberangriffe waren schon immer automatisiert. Bots suchen seit Jahren das Internet nach offenen Administrationsbereichen, bekannten Sicherheitslücken, unsicheren Passwörtern oder falsch konfigurierten Servern ab.
Bislang mussten solche Werkzeuge jedoch vergleichsweise gezielt entwickelt werden. Ein Angreifer benötigte Kenntnisse über die jeweilige Plattform, ihre Verzeichnisstruktur, typische Erweiterungen und mögliche Schwachstellen. Bei einem weniger verbreiteten Shopsystem konnte der Aufwand in keinem attraktiven Verhältnis zur Zahl potenzieller Ziele stehen.
KI senkt diese Hürde.
Dokumentationen, öffentlich zugänglicher Quellcode, Fehlermeldungen und technische Merkmale einer Website können automatisiert analysiert werden. Bestehende Angriffsmuster lassen sich schneller auf andere Technologien übertragen.
Auch Personen mit begrenztem Fachwissen können sich Programme erstellen lassen, die Websites untersuchen, Daten sammeln oder bekannte Schwachstellen testen.
Die entscheidende Veränderung lautet daher:
OXID eShop ist nicht plötzlich unsicherer geworden. Aber automatisierte Angriffe auf OXID-Shops werden einfacher, schneller und wirtschaftlicher.
Damit verliert die vergleichsweise geringe Verbreitung von OXID zunehmend ihre bisherige Schutzwirkung.
KI kann Cyberangriffe selbstständig ausführen
Wie konkret diese Entwicklung inzwischen geworden ist, haben Vorfälle bei OpenAI und Anthropic im Sommer 2026 gezeigt.
Bei Sicherheitstests von OpenAI gelangten KI-Modelle aus einer vorgesehenen Testumgebung ins öffentliche Internet und verschafften sich Zugang zu einem externen Unternehmen. OpenAI bezeichnete den Vorgang selbst als einen beispiellosen Cybervorfall.
Wenige Tage später wurde ein ähnlicher Fall bei Anthropic bekannt. Dort drang ein KI-Agent während Testläufen ungeplant in die Systeme von drei realen Unternehmen ein. Nach Angaben des Unternehmens war ein Programmierfehler die Ursache.
Diese Fälle sind außergewöhnlich. Sie zeigen aber, dass KI-Systeme längst nicht mehr nur Texte über mögliche Cyberangriffe verfassen. Sie können technische Aufgaben ausführen, Schwachstellen untersuchen und Handlungen in realen IT-Systemen vornehmen.
Für Betreiber eines Onlineshops bedeutet das nicht, dass morgen eine autonome KI gezielt ihren Shop angreifen wird. Es bedeutet jedoch, dass die technischen Möglichkeiten zur Automatisierung von Angriffen bereits vorhanden sind und sich sehr schnell weiterentwickeln.
Kriminelle können diese Möglichkeiten bewusst einsetzen. Gleichzeitig können KI-Agenten auch durch Fehler, unzureichende Begrenzungen oder falsche Anweisungen Schäden verursachen.
Nicht jeder KI-verursachte Ausfall ist ein Hackerangriff
In unserer täglichen Arbeit beobachten wir noch ein weiteres Phänomen, das bislang deutlich weniger öffentliche Aufmerksamkeit erhält.
Nicht jede massive Belastung eines Onlineshops ist ein gezielter DDoS-Angriff. Immer häufiger können auch schlecht konfigurierte Bots, Scraper und KI-generierte Programme DDoS-ähnliche Lastspitzen verursachen.
Ein Nutzer möchte beispielsweise:
- Produktdaten aus mehreren Onlineshops zusammentragen,
- Preise regelmäßig vergleichen,
- Produktbilder oder Beschreibungen herunterladen,
- Inhalte für ein KI-Modell indexieren,
- Suchergebnisse analysieren,
- oder einen eigenen Einkaufs- beziehungsweise Rechercheagenten entwickeln.
Mit KI-Unterstützung lässt sich ein entsprechendes Programm heute innerhalb kurzer Zeit erzeugen. Der Nutzer muss dafür weder professioneller Softwareentwickler sein noch verstehen, welche Belastung seine Anwendung auf der Gegenseite verursacht.
Ein schlecht entwickelter Crawler kann tausende Produktseiten in kurzer Zeit abrufen, Filterkombinationen systematisch durchprobieren oder immer wieder rechenintensive Suchanfragen auslösen. Werden mehrere Prozesse parallel gestartet, entsteht für den betroffenen Shop ein Lastbild, das einem absichtlichen Angriff ähneln kann.
Das Ergebnis kann unabhängig von der Absicht dasselbe sein:
- stark verlängerte Ladezeiten,
- ausgelastete PHP-Prozesse,
- überlastete Datenbanken,
- wachsende Logdateien,
- steigende Hosting- und Infrastrukturkosten,
- Abbrüche im Checkout,
- oder ein vollständiger Ausfall des Shops.
Die neue Gefahr geht deshalb nicht ausschließlich von professionellen Cyberkriminellen aus.
Auch unqualifiziert entwickelte KI-Agenten und Scraper können eine ungeschützte Shop-Infrastruktur unbeabsichtigt erheblich beeinträchtigen oder vollständig lahmlegen.
Gerade das sogenannte Vibe Coding verstärkt dieses Risiko. KI ermöglicht es Menschen ohne tiefergehendes Verständnis der zugrunde liegenden Technik, funktionsfähigen Code zu erzeugen. Was häufig fehlt, sind Begrenzungen, Fehlerbehandlung, Pausen zwischen Abrufen, eine kontrollierte Parallelisierung und ein Bewusstsein für die Auswirkungen auf fremde Systeme.
Warum OXID-Shops davon besonders betroffen sein können
Viele OXID-Shops sind über Jahre gewachsene, stark individualisierte Systeme. Sie verfügen häufig über eigene Module, Warenwirtschaftsanbindungen, individuelle Preislogiken, umfangreiche Such- und Filterfunktionen sowie weitere Schnittstellen.
Das ist grundsätzlich eine Stärke von OXID. Die Plattform eignet sich sehr gut für individuelle und komplexe E-Commerce-Projekte.
Gleichzeitig kann diese Individualisierung dazu führen, dass Updates aufgeschoben werden. Ein Versionswechsel betrifft dann nicht nur den Shop-Core, sondern möglicherweise auch zahlreiche Module, Templates, Schnittstellen und kundenspezifische Anpassungen.
Nach unserer Erfahrung läuft ein großer Teil der bestehenden OXID-Shops deshalb nicht auf der jeweils neuesten Version. Viele Betreiber verwenden weiterhin OXID 6.5 oder eine OXID-7-Version zwischen 7.0 und 7.4.
Das bedeutet nicht automatisch, dass diese Shops unsicher sind.
Ein gepflegter OXID-6.5-Shop mit aktuellen Sicherheitskorrekturen, einer modernen Infrastruktur, wirksamer Zugriffskontrolle und aktivem Monitoring kann deutlich besser geschützt sein als ein schlecht administrierter Shop auf einer neueren Versionsnummer.
Die Versionsnummer allein ist deshalb kein ausreichender Maßstab.
Mit zunehmendem Alter einer Installation wächst jedoch die Wahrscheinlichkeit, dass nicht nur der Shop-Core, sondern auch weitere Bestandteile nicht mehr dem aktuellen technischen Stand entsprechen:
- PHP-Version,
- Datenbankserver,
- Composer-Abhängigkeiten,
- JavaScript-Bibliotheken,
- Drittanbieter-Module,
- Webserver-Konfiguration,
- Betriebssystem,
- Administrationszugänge,
- oder vorgeschaltete Sicherheitsmechanismen.
Eine Sicherheitsbetrachtung darf sich daher nicht darauf beschränken, im Backend nach der OXID-Versionsnummer zu schauen.
Was OXID selbst zu unterstützten Versionen sagt
OXID eSales unterscheidet in seinem Release-Plan zwischen Maintenance-, Legacy- und älteren Versionen.
Die Maintenance-Version ist die jeweils neueste öffentlich freigegebene Version und erhält die meisten Fehlerbehebungen. Legacy-Versionen erhalten noch ausgewählte wichtige Fixes. OXID weist gleichzeitig darauf hin, dass überholte Softwarestände nicht alle Patches bekommen und empfiehlt für Stabilität und Sicherheit den Einsatz unterstützter Versionen.
Zum Zeitpunkt dieses Beitrags ist OXID eShop 7.5 die aktuelle Produktgeneration. OXID eShop 7.5.0 wurde am 2. Juni 2026 veröffentlicht.
Besonders eindeutig ist die offizielle OXID-Sicherheitsdokumentation. Dort erklärt OXID, dass bei neuen Sicherheitshinweisen lediglich geprüft wird, ob unterstützte OXID-eShop-Versionen betroffen sind.
Ältere, nicht unterstützte Versionen können dieselben Sicherheitslücken enthalten, werden aber nicht mehr regulär geprüft. Sicherheitskorrekturen und Fehlerbehebungen stellt OXID für solche Versionen nicht bereit. Betreiber werden ausdrücklich dazu aufgefordert, ihre Installation zu aktualisieren.
Das bedeutet nicht, dass jeder nicht mehr unterstützte Shop bereits kompromittiert ist.
Es bedeutet aber:
- Neue Sicherheitslücken werden für diese Version möglicherweise nicht mehr untersucht.
- Betreiber erhalten keine verlässliche Aussage, ob ihre Installation betroffen ist.
- Ein offizieller Patch für die eingesetzte Version ist nicht zu erwarten.
- Individuelle Rückportierungen können erforderlich und aufwendig sein.
- Das Risiko muss vollständig vom Betreiber und seinem technischen Dienstleister bewertet werden.
Auch OXID 6.5 hat in der Vergangenheit sicherheitsrelevante Aktualisierungen erhalten. So wurde OXID eShop 6.5.4 ausdrücklich veröffentlicht, um eine Sicherheitslücke in Composer zu schließen. Mit OXID eShop 6.5.5 wurden weitere Sicherheitslücken behoben.
Das zeigt, weshalb selbst innerhalb derselben Hauptversion der genaue Patchstand entscheidend ist. Ein Shop auf OXID 6.5.0 ist sicherheitstechnisch nicht mit einer aktuelleren OXID-6.5-Installation gleichzusetzen.
Ein funktionierender Shop ist nicht automatisch ein sicherer Shop
Eine der größten Schwierigkeiten bei der Bewertung älterer Systeme ist ihr scheinbar problemloser Betrieb.
Der Shop ist erreichbar. Kunden können bestellen. Zahlungen werden verarbeitet. Die Warenwirtschaft erhält ihre Daten.
Der Umsatz läuft weiter.
Damit entsteht leicht der Eindruck, es gebe keinen akuten Handlungsbedarf.
Technische Sicherheit zeigt sich jedoch nicht daran, dass eine Anwendung heute noch funktioniert. Sie zeigt sich unter anderem daran, wie sie auf neue Bedrohungen reagiert, wie schnell Sicherheitslücken geschlossen werden können und ob ungewöhnliche Aktivitäten überhaupt erkannt werden.
Ein über Jahre unveränderter Shop kann zuverlässig funktionieren und trotzdem erhebliche Risiken enthalten.
Besonders kritisch wird es, wenn mehrere Faktoren zusammentreffen:
- ein alter oder nicht mehr vollständig unterstützter Softwarestand,
- fehlende Sicherheitsupdates,
- öffentlich zugängliche Administrationsbereiche,
- keine Mehrfaktor-Authentifizierung,
- fehlendes Rate Limiting,
- kein wirksamer Schutz vor automatisierten Zugriffen,
- kein zentrales Monitoring,
- unzureichende Protokollierung,
- und eine Infrastruktur, die bereits bei moderater Zusatzlast an ihre Grenzen gerät.
Die entscheidende Frage lautet deshalb nicht:
Läuft der Shop noch?
Sondern:
Ist der Shop auf die heutige Bedrohungslage vorbereitet und können wir ungewöhnliche Zugriffe rechtzeitig erkennen und begrenzen?
Sicherheit ist mehr als ein OXID-Update
Ein Update auf eine unterstützte OXID-Version ist ein wichtiger Bestandteil einer Sicherheitsstrategie. Es löst jedoch nicht automatisch alle Probleme.
Auch ein aktueller OXID-Shop kann überlastet werden, wenn Bots unbegrenzt Suchanfragen auslösen oder systematisch dynamische URLs abrufen. Ebenso kann eine aktuelle Plattform durch unsichere Passwörter, fehlerhafte Module oder eine schlecht konfigurierte Serverumgebung gefährdet sein.
OXID-Sicherheit muss deshalb auf mehreren Ebenen betrachtet werden.
Shop und Erweiterungen
Der OXID-Core, eingesetzte Module, Themes und externe Bibliotheken sollten regelmäßig aktualisiert und auf bekannte Schwachstellen geprüft werden.
Besonders bei individuellen Modulen ist zu klären, ob diese weiterhin gepflegt werden und mit aktuellen PHP-, Datenbank- und OXID-Versionen kompatibel sind.
Server und Infrastruktur
Zum Shop gehören auch Webserver, PHP, Datenbank, Betriebssystem, Caching-Systeme und weitere Dienste.
Nicht selten wird ein OXID-Update aufgeschoben, weil die bestehende Anwendung nur mit einer ebenfalls veralteten PHP- oder Datenbankversion kompatibel ist. Dadurch entsteht eine Abhängigkeit, bei der ein einzelner alter Softwarebestandteil die Modernisierung der gesamten Umgebung verhindert.
Zugriffe und Berechtigungen
Administrationsbereiche sollten nicht unnötig offen erreichbar sein. Zugänge benötigen sichere Passwörter, klar geregelte Berechtigungen und möglichst eine zusätzliche Authentifizierungsebene.
Ehemalige Dienstleister, Mitarbeiter oder Testzugänge dürfen nicht dauerhaft aktiv bleiben.
Schutz vor Bots und automatisierten Anfragen
Öffentlich erreichbare Onlineshops können automatisierte Zugriffe nicht vollständig verhindern. Suchmaschinen, Preisportale, Marktplätze und legitime Dienste benötigen häufig Zugriff auf Produktdaten.
Entscheidend ist, schädliche oder übermäßige Zugriffe zu erkennen und zu begrenzen.
Dazu gehören beispielsweise:
- Rate Limiting,
- Erkennung ungewöhnlicher Abrufmuster,
- Begrenzung paralleler Anfragen,
- Regeln für besonders rechenintensive URLs,
- Schutz von Such- und Filterfunktionen,
- Caching,
- Blockierung auffälliger Clients,
- und eine vorgeschaltete Schutzebene für den Webtraffic.
Dabei sollte nicht jedes automatisierte System pauschal gesperrt werden. Vielmehr geht es darum, zwischen gewünschter Indexierung, legitimen Schnittstellen und missbräuchlicher beziehungsweise unkontrollierter Nutzung zu unterscheiden.
Monitoring und Reaktionsfähigkeit
Viele Angriffe oder Überlastungen werden erst bemerkt, wenn Kunden nicht mehr bestellen können.
Ein wirkungsvolles Monitoring sollte deshalb nicht nur prüfen, ob die Startseite erreichbar ist. Es sollte auch ungewöhnliche Serverlast, Fehlerraten, Antwortzeiten, Datenbankprobleme und auffällige Zugriffsmuster erkennen.
Ebenso wichtig ist ein klarer Prozess für den Ernstfall:
- Wer erhält die Warnung?
- Wer kann Zugriffe begrenzen?
- Wer analysiert die Ursache?
- Wie schnell lassen sich Regeln anpassen?
- Funktionieren Backups und Wiederherstellung?
- Wann müssen Kunden, Zahlungsanbieter oder Behörden informiert werden?
Die DSGVO verlangt ein angemessenes Sicherheitsniveau
Ein Onlineshop verarbeitet personenbezogene Daten. Dazu gehören abhängig vom Geschäftsmodell unter anderem Namen, Adressen, Kontaktdaten, Bestellungen, Kundenkonten und teilweise weitere vertrauliche Informationen.
Artikel 32 der Datenschutz-Grundverordnung verpflichtet Verantwortliche und Auftragsverarbeiter dazu, geeignete technische und organisatorische Maßnahmen zu treffen. Diese müssen dem jeweiligen Risiko entsprechen und unter anderem den Stand der Technik berücksichtigen.
Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit weist darauf hin, dass Verantwortliche ein angemessenes Schutzniveau gewährleisten und ihre Maßnahmen am Stand der Technik ausrichten müssen.
Die DSGVO schreibt weder eine konkrete OXID-Version noch ein bestimmtes Updateintervall vor. Ein nicht aktueller Shop ist daher nicht automatisch ein Datenschutzverstoß.
Betreiber müssen aber nachvollziehbar darlegen können, weshalb die eingesetzten Maßnahmen trotz des vorhandenen Risikos angemessen sind.
Bei einer seit Jahren nicht unterstützten Software, fehlendem Monitoring und einer ungeschützten Infrastruktur wird diese Begründung im Schadensfall schwierig.
Für Verstöße gegen die Pflichten zur Sicherheit der Verarbeitung sieht die DSGVO einen erheblichen Bußgeldrahmen vor.
Die konkrete Höhe hängt stets vom Einzelfall ab, unter anderem von Art, Schwere, Dauer und Verschulden. Die oft genannten zwei Prozent des weltweiten Vorjahresumsatzes sind daher keine automatische Strafe nach einem Datenabfluss, sondern eine mögliche gesetzliche Höchstgrenze für bestimmte Verstöße.
Entscheidender als die theoretische Bußgeldhöhe sind häufig ohnehin die unmittelbaren Folgen eines Vorfalls:
- Betriebsunterbrechung,
- entgangener Umsatz,
- Kosten für Analyse und Wiederherstellung,
- mögliche Informationspflichten,
- Vertrauensverlust bei Kunden,
- und langfristige Schäden für die Marke.
Müssen jetzt alle OXID-Shops sofort auf Version 7.5 wechseln?
Ein sofortiges Update auf OXID 7.5 ist nicht in jedem Projekt realistisch.
Gerade stark individualisierte OXID-6-Shops können nicht ohne Vorbereitung migriert werden. Module müssen geprüft oder ersetzt, Templates angepasst, Schnittstellen getestet und möglicherweise auch die Serverinfrastruktur modernisiert werden.
Ein überhastetes Update kann selbst neue Risiken und Ausfälle verursachen.
Das darf jedoch nicht als Begründung dienen, die bestehende Situation über Jahre unverändert fortzuführen.
Zwischen „Wir migrieren morgen vollständig“ und „Wir lassen alles wie bisher“ gibt es zahlreiche sinnvolle Zwischenschritte.
Der erste Schritt sollte eine ehrliche technische Bestandsaufnahme sein:
- Welche OXID-Version und welcher Patchstand werden tatsächlich eingesetzt?
- Welche Module und externen Bibliotheken sind installiert?
- Welche Komponenten werden noch aktiv gepflegt?
- Welche PHP-, Datenbank- und Serverversionen kommen zum Einsatz?
- Welche öffentlich erreichbaren Angriffsflächen bestehen?
- Wie werden Bots und übermäßige Zugriffe erkannt?
- Gibt es ein funktionierendes Monitoring?
- Wann wurden Wiederherstellung und Backups zuletzt getestet?
- Welche kurzfristigen Schutzmaßnahmen sind möglich?
- Wie sieht ein realistischer Upgradepfad aus?
Auf dieser Grundlage lässt sich entscheiden, welche Maßnahmen sofort notwendig sind und welche im Rahmen einer geplanten Modernisierung umgesetzt werden können.
OXID-Sicherheit muss im KI-Zeitalter neu bewertet werden
OXID eShop war aufgrund seiner vergleichsweise geringen Verbreitung lange kein bevorzugtes Ziel breit angelegter Angriffskampagnen.
Auf diesen Umstand sollten sich Shopbetreiber heute nicht mehr verlassen.
KI senkt den Aufwand, technische Systeme zu analysieren, Programme zu entwickeln und automatisierte Angriffe zu skalieren. Zugleich entstehen neue Belastungen durch KI-Agenten, Scraper und schlecht kontrollierte Automatisierungen, die nicht einmal zwingend eine kriminelle Absicht verfolgen müssen.
Damit verändert sich die Bedrohungslage auch für OXID-Shops.
Das gilt nicht nur für extreme Einzelfälle mit sehr alten OXID-4- oder OXID-5-Versionen. Es betrifft ebenso OXID-6.5- und ältere OXID-7-Projekte, wenn Sicherheitskorrekturen, Infrastruktur, Zugriffsschutz und Monitoring nicht regelmäßig überprüft werden.
Die wichtigste Frage lautet nicht, ob der Shop gestern noch zuverlässig funktioniert hat.
Entscheidend ist, ob seine Sicherheitsstrategie für eine Welt ausgelegt ist, in der automatisierte Zugriffe und KI-gestützte Angriffe schneller, günstiger und leichter verfügbar werden.
Wer diese Frage nicht eindeutig beantworten kann, benötigt nicht zwangsläufig sofort ein großes Migrationsprojekt. Er benötigt zunächst Transparenz über den aktuellen Zustand und einen realistischen Plan, um bestehende Risiken zu reduzieren.