Shopwares neue Sicherheitsrealität

Worum es geht

Am 27. Oktober 2026 hat Shopware einen Beitrag mit dem Titel A new security reality for commerce veröffentlicht, geschrieben von Jonas Elfering, parallel auch auf dev.to. Er erklärt, wie sich die Sicherheitslage für Shopsysteme verändert hat und was Shopware selbst daran ändert. Der interessantere Teil steht am Ende: konkrete Anweisungen an Betreiber, Agenturen und Erweiterungshersteller, darunter eine geänderte Empfehlung, die die Wartungspraxis vieler Shops betrifft. Dieser Beitrag übersetzt das in den Alltag eines Shops. Die Quellen stehen jeweils verlinkt, alles Weitere ist Einordnung.

Was sich geändert hat

Die Kernaussage ist einfach: KI-Werkzeuge beschleunigen die Suche nach Schwachstellen, für Sicherheitsforscher ebenso wie für Angreifer. Shopware beschreibt zwei Folgen. Erstens steigt die Zahl der Meldungen über das Bug-Bounty-Programm und die Zahl der Sicherheitshinweise. Ein Diagramm im Beitrag zeigt den Verlauf, konkrete Zahlen nennt Shopware nicht, und es weist selbst darauf hin, dass mehr Funde nicht bedeuten, dass die Software unsicherer geworden ist. Zweitens, und das ist für den Betrieb entscheidend: Nach der Veröffentlichung eines Sicherheitshinweises sieht Shopware automatisierte Angriffsversuche innerhalb von Tagen. Die Zeit zwischen Hinweis und Angriff ist auf wenige Tage geschrumpft.

Shopware ordnet das als Branchenthema ein und belegt es mit Beispielen aus dem Oktober: das PHP-Sicherheitsrelease vom 21. Oktober, bei dem die Gruppe hinter php2shell mit KI-Hilfe die Ausnutzung einer lange bekannten Schwäche demonstrierte; Sansec, die bei Magento vier Angriffswege innerhalb von 24 Stunden nach dem Adobe-Patch nachstellten; Patchstack, die bei WordPress Sondierungen wenige Stunden nach einem Patch beobachteten. Was php2shell für Shopware-Betreiber bedeutet hat, steht im Beitrag zur Serverwartung.

Was Shopware selbst ändert

Vier Punkte nennt der Beitrag. Das Sicherheitsteam wird vergrößert, mit mehr Design- und Code-Reviews und besseren automatischen Prüfungen. Neben externen Penetrationstests und dem Bug-Bounty-Programm setzt Shopware jetzt auch KI-Modelle ein, um aktiv nach Schwachstellen zu suchen, mit dem ausdrücklichen Hinweis, dass jeder Fund validiert werden muss und ein Scan ohne Fund keine Sicherheit beweist. Systemgrenzen sollen verhindern, dass aus einem ersten Zugriff die Kontrolle über den ganzen Shop wird, dazu bessere forensische Daten. Und die Auslieferung von Sicherheitspatches wird so überarbeitet, dass sie ohne großes Upgrade-Projekt einspielbar sind.

Die Konsequenz formuliert Shopware offen: Es wird mehr Sicherheitsfixes und häufigere Sicherheitsreleases geben. Wer bisher mit dem monatlichen Release-Rhythmus plant, muss sich auf Zwischenreleases einstellen, die nicht warten können.

Die geänderte Empfehlung: das Security Plugin bleibt drin

Bisher galt das Shopware Security Plugin als Überbrückung: installieren, wenn ein Plattform-Update nicht sofort möglich ist, damit bekannte Lücken im Kern trotzdem geschlossen sind. Das ändert sich. Shopware empfiehlt jetzt, das Plugin dauerhaft installiert und aktiviert zu halten und es mit einer zur Shop-Version passenden Fassung aktuell zu halten, auch wenn der Shop selbst vollständig aktuell ist. Der Grund ist die Geschwindigkeit: Ein Plugin-Update ist in Minuten eingespielt, ein Plattform-Update braucht Test und Freigabe.

Zwei Einschränkungen nennt Shopware ausdrücklich, und sie sind wichtig. Das Plugin schließt bekannte Schwachstellen im Shopware-Kern, ersetzt aber keine Updates von PHP, von Drittanbieter-Abhängigkeiten, von Erweiterungen oder von Shopware selbst. Und zusätzliche Härtungen kommen nur in den regulären Releases und werden meist nicht zurückportiert. Wer also nur das Plugin pflegt und die Platform liegen lässt, hat die bekannten Löcher gestopft, aber nicht den Stand, auf dem Shopware weiter absichert. Die behobenen Probleme je Plugin-Version stehen in dessen Changelog, der Leitfaden zum Plugin beschreibt den Einsatz.

Drei Dinge, die jetzt geregelt sein müssen

Ein eigener Weg für Sicherheitsupdates. Shopware sagt es deutlich: Sicherheitsreleases des Plugins sofort einspielen, nicht im nächsten wöchentlichen oder monatlichen Wartungsfenster. Validierung bleibt wichtig, aber sie braucht für Sicherheitsupdates einen eigenen, schnellen Prozess, getrennt von Feature-Releases. In der Praxis heißt das: Ein Plugin-Update auf der Staging-Umgebung durchklicken und live bringen muss am selben Tag gehen, nicht erst nach dem nächsten Sprint.

Zuständigkeiten, die vorher feststehen. Sicherheitshinweise müssen bei jemandem ankommen, der handeln kann. Shopware formuliert es so: Eine E-Mail zu erhalten ist nicht dasselbe wie den Shop zu schützen. Agenturen und Betreiber sollen vorab festlegen, wer die Hinweise bekommt, wer prüft, ob der eigene Shop betroffen ist, und wer das Update ausrollt. Das klingt trivial und ist in vielen Shops nicht geregelt, besonders dort, wo die Agentur das Projekt gebaut hat und seitdem niemand den Betrieb verantwortet. Genau diese Lücke ist der häufigste Grund, warum Shops bei einer Wartungsübernahme mit monatelangem Rückstand ankommen.

Eine Version, die noch Sicherheitssupport hat. Alles oben nützt nichts, wenn der Shopware-Zweig ausgelaufen ist. Shopware verweist auf seine Release-Policy; welche Zweige noch Sicherheitsfixes bekommen und welches PHP sie vertragen, steht gesammelt unter Shopware-Versionen und Supportstatus. Dort steht auch der aktuelle Patchstand je Zweig, an dem sich der eigene Shop messen lässt.

Was Shopware zu Hosting und Erweiterungen sagt

Zwei weitere Abschnitte lohnen den Blick. Beim Hosting-Modell unterscheidet Shopware klar: In der SaaS-Variante übernimmt Shopware Plattform- und Sicherheitsupdates, in PaaS Native nur Server, Netzwerk, Datenbank, Backups und eine Web Application Firewall. Anwendung, Updates, Erweiterungen, Abhängigkeiten und die Wahl einer unterstützten PHP-Version bleiben beim Kunden oder seiner Agentur. Der Satz dazu: Verwaltete Infrastruktur und eine Firewall ersetzen keine zeitnahen Anwendungsupdates. Für alle, die klassisch selbst hosten, gilt das ohnehin.

An Erweiterungshersteller richtet sich eine Prüfliste, die auch Betreiber kennen sollten, weil sie beim Einkauf von Erweiterungen hilft: Werden Rechte serverseitig geprüft und nicht nur in der Administration? Werden Eingaben vor Datenbank, Templates und Dateioperationen sicher behandelt? Sind die Abhängigkeiten aktuell? Lässt sich begrenzter Zugriff auf eine Funktion mit anderen kombinieren, um mehr zu erreichen? Shopware schreibt, dass Drittanbieter-Erweiterungen in untersuchten Angriffen bereits Teil der Angriffskette waren. Wer viele Erweiterungen aus verschiedenen Quellen betreibt, hat damit eine Angriffsfläche, die kein Plattform-Update schließt.

Einordnung

Der Beitrag kommt von Shopware selbst, und das sollte man beim Lesen im Kopf behalten. Die Aussage, dass mehr Funde den Shop nicht unsicherer machen, ist Herstellersicht. Richtig ist sie trotzdem, solange die Funde behoben und die Fixes eingespielt werden, und genau darauf läuft der ganze Text hinaus. Die Verantwortung für den zweiten Teil liegt beim Betreiber. Was wirklich in einem Shop steckt, zeigt erst eine Bestandsaufnahme mit Zugang: Versionen, Erweiterungen, Theme, Sicherungen, Zuständigkeiten. Wer beides nicht selbst leisten will, holt sich jemanden, der es als Routine betreibt.

Supportstatus aller Versionen

Welche Shopware-, PHP- und Datenbank-Version noch Updates bekommt und wo der aktuelle Patchstand liegt, steht dauerhaft unter Shopware-Versionen und Supportstatus. Die Seite wird mit jedem Release nachgezogen.