Shopware-Sicherheitsupdate: Diese Lücken sollten Betreiber jetzt schließen

Im August 2026 sind mit Shopware 6.6.10.23 und Shopware 6.7.13.1 zwei neue Versionen erschienen, die vor allem sicherheitsrelevante Korrekturen enthalten. Für Betreiber von Onlineshops ist das Update deshalb mehr ale eine gewöhnliche Versionspflege. Mehrere Schwachstellen betreffen sicherheitskritische Bereiche.

Wir empfehlen Shopbetreibern daher dringend, eine der beiden für den jeweiligen Systemstand geeigneten Versionen zeitnah einzuspielen. Gerade bei öffentlich erreichbaren Shops ist es wichtig, Sicherheitsupdates nicht erst im Rahmen des nächsten regulären Wartungsfenster zu berücksichtigen. Je länger eine bekannte Schwachstelle in einem produktiven System vorhanden ist, desto größer ist grundsätzlich das Zeitfenster für einen möglichen Angriff.

Mehrere Schwachstellen betreffen die neuen Versionen

Die Sicherheitskorrekturen betreffen unter anderem die Ausführung von Schadcode, die Übernahme von Administratorkonten, SQL-Injection, Rechteausweitungen, Server-Side Request Forgery (SSRF) und den unbefugten Zugriff auf Kundendaten.

Einige der Schwachstellen setzen eine bestimmte Basis voraus, beispielsweise einen angemeldeten Benutzer mit speziellen Berechtigungen oder einen gültigen Sales-Channel-Zugriffsschlüssel. Das bedeutet jedoch nicht, dass sie für einen produktiven Shop vernachlässigbar wären. Moderne Shops bestehen aus zahlreichen Schnittstellen, Apps, Integrationen und Benutzerkonten. Eine Schwachstelle an einer einzelnen Stelle kann deshalb Teil einer komplexeren Angriffskette werden.

Schadcode über manipulierte App Scripts

Eine besonders kritische Klasse von Schwachstellen betrifft die Ausführung von Code. In den App Scripts konnten die vorgesehenen Beschränkungen für die Ausführung bestimmter Funktionen umgangen werden.

Eine manipulierte oder kompromittierte App hätte dadurch unter Umständen beliebige PHP-Funktionen und Betriebssystembefehle mit den Rechten des Webservers ausführen können. Das ist deshalb problematisch, weil ein Webserver-Prozess in einer Shopware-Installation typischerweise Zugriff auf zahlreiche für den Betrieb relevante Ressourcen besitzt.

Je nach Serverkonfiguration könnten dadurch beispielsweise Konfigurationsdateien mit Zugangsdaten ausgelesen, Dateien verändert oder interne Dienste angesprochen werden. Im schlimmsten Fall kann aus einer solchen Codeausführung eine vollständige Kompromittierung des Shops entstehen.

Passwort-Wiederherstellung nutzt jetzt eine vertrauenswürdige Herkunft

Auch der Prozess zur Wiederherstellung von Administrationspasswörtern wurde abgesichert.

Bei der Generierung von Passwort-Recovery-Links war die verwendete Host-Adresse bislang nicht ausreichend gegen Manipulation abgesichert. Unter bestimmten Voraussetzungen konnte dadurch ein Angreifer einen manipulierten Link zur Passwortzurücksetzung für ein bekanntes Administratorkonto erzeugen.

Genau solche Mechanismen sind für Angreifer interessant: Eine Schwachstelle muss nicht zwangsläufig das Passwort selbst offenlegen. Es genügt unter Umständen, den Prozess zur Wiederherstellung eines Kontos so zu beeinflussen, dass ein legitimer Benutzer eine Anfrage an eine vom Angreifer kontrollierte Adresse ausführt.

Shopware verwendet deshalb bei der Administration-Passwortwiederherstellung nun die in APP_URL hinterlegte öffentliche URL, wenn keine vertrauenswürdigen Hosts konfiguriert sind. Sind Trusted Hosts eingerichtet, kann weiterhin der Request-Host verwendet werden, nachdem Symfony diesen validiert hat.

Für Betreiber ergibt sich daraus eine wichtige Konfigurationsprüfung: APP_URL sollte die tatsächlich öffentliche HTTP- oder HTTPS-Adresse des Shops enthalten.

SQL-Injection über benutzerdefinierte Entitäten und Felder verhindert

Eine weitere sicherheitsrelevante Änderung betrifft individuelle Entitäten und Felder. Definitionen aus Resources/entities.xml werden beim Aufbau des Datenbankschemas unter anderem zu Tabellen- und Spaltennamen.

Solche Bezeichner dürfen deshalb nicht beliebige Zeichen enthalten. Shopware validiert Entity- und Field-Namen nun bereits bei der Installation beziehungsweise Aktualisierung einer App oder eines Plugins. Erlaubt sind nur geeignete Zeichen wie Buchstaben, Ziffern und Unterstriche sowie die von MySQL beziehungsweise MariaDB unterstützten nicht-ASCII-Zeichen.

Problematische Manifestdefinitionen, beispielsweise mit Leerzeichen oder bestimmten Satz- und Sonderzeichen wie -, werden mit einer verständlichen Fehlermeldung abgelehnt.

Der entscheidende Sicherheitsaspekt liegt darin, dass Daten, die später Bestandteil eines Datenbankschemas oder einer SQL-Anweisung werden, nicht ungeprüft aus externen Definitionen übernommen werden dürfen. Eine konsequente Validierung an der Eingangsgrenze verhindert, dass manipulierte Namen später in einer sicherheitskritischen Verarbeitungsschicht Probleme verursachen.

Store API: Aggregationsnamen werden strenger geprüft

Auch die Store API erhält zusätzliche Eingabevalidierung. Aggregationsnamen, die über Store-API-Kriterien übergeben werden, dürfen keine Steuerzeichen mehr enthalten.

Shopware weist ungültige Namen bereits zurück, bevor daraus eine Aggregationsabfrage aufgebaut wird. Für Integrationen bedeutet das: Aggregationen sollten ausschließlich mit druckbaren, technisch geeigneten Namen angelegt beziehungsweise abgefragt werden.

Schutz vor unzulässiger Rechteausweitung in der Administration

Eine besonders wichtige Korrektur betrifft die Rechteverwaltung der Administration.

Generische Admin-API-Schreibzugriffe können nun keine acl_role-Entitäten mehr erstellen oder verändern. Gleichzeitig bleiben direkte DAL-Schreibzugriffe auf geschützte admin-Felder von Benutzern und Integrationen systemintern beschränkt. Die dafür vorgesehenen Administration-API-Controller behalten ihre autorisierten Schreibwege.

Damit wird verhindert, dass ein allgemeiner Schreibmechanismus genutzt werden kann, um sicherheitskritische Berechtigungsinformationen auf einem nicht dafür vorgesehenen Weg zu verändern.

Für Entwickler von Shopware-Erweiterungen ist außerdem relevant, dass die Methode

Shopware.Service('integrationService').updateAdmin()

deprecated ist und mit Shopware 6.8 entfernt werden soll. Stattdessen sollte künftig das Integration-Repository verwendet werden, beispielsweise über repositoryFactory und das Repository für integration.

Produktbewertungen unterliegen jetzt auch bei verschachtelten Abfragen den Sichtbarkeitsregeln

Shopware korrigiert außerdem das Verhalten von productReviews-Associations innerhalb verschachtelter Store-API-Kriterien.

Für Produktbewertungen gelten die bekannten Sichtbarkeitsregeln: Freigegebene Bewertungen dürfen angezeigt werden; zusätzlich kann der angemeldete Kunde seine eigenen noch ausstehenden Bewertungen sehen. Diese Regeln wurden bislang bei der obersten productReviews-Association angewendet, nicht jedoch in gleicher Weise bei verschachtelten Associations.

Zu große Sales-Channel-Kriterien werden abgelehnt

Ein weiterer Schutzmechanismus betrifft sehr komplexe Criteria-Strukturen.

Das SalesChannelRepository wendet die Einschränkungen eines Sales Channels, beispielsweise die jeweiligen Sales-Channel-Scopes und entity-spezifische Filter wie die Produktverfügbarkeit, auf die Kriterien an. Bisher wurden dabei nur die ersten 99 verschachtelten Criteria-Knoten berücksichtigt. Bei darüber hinausgehenden Strukturen konnten weitere Knoten ohne die entsprechenden Einschränkungen verarbeitet werden.

Dadurch hätte eine extrem große Criteria-Struktur dazu führen können, dass Daten nicht mehr vollständig unter den vorgesehenen Einschränkungen verarbeitet wurden.

Shopware lehnt solche Anfragen nun mit HTTP 400 und dem Fehlercode SYSTEM__CRITERIA_TOO_MANY_NESTED_CRITERIA ab.

Für normale Storefront-Anfragen ist diese Grenze nicht relevant. Integrationen, die ungewöhnlich große Criteria-Strukturen erzeugen, sollten diese stattdessen auf mehrere Requests aufteilen.

Mediendateiendungen werden bei jedem Schreibzugriff geprüft

Auch der Umgang mit Mediendateien wurde gehärtet.

Direkte Schreibzugriffe auf media.fileExtension verwenden nun dieselbe konfigurierte Allowlist für Dateiendungen wie reguläre Medienuploads. Nicht erlaubte öffentliche oder private Dateiendungen werden mit dem Fehlercode MEDIA_ILLEGAL_FILE_EXTENSION zurückgewiesen.

Das ist besonders wichtig, weil Dateiendungen in einer Webanwendung nicht lediglich eine kosmetische Eigenschaft einer Datei sind. Je nach Serverkonfiguration kann die Interpretation einer Datei davon abhängen, welche Endung sie besitzt und in welchem Verzeichnis sie gespeichert wird.

Eine konsequente Validierung bei jedem Schreibweg verhindert deshalb, dass eine bestehende Upload-Prüfung durch einen alternativen Datenzugriff umgangen werden kann.

Diese Korrektur ist auch deshalb relevant, weil in Shopware 6.7.13.1 eine weitere Schwachstelle im Zusammenhang mit Mediendateien geschlossen wird: Unter bestimmten Voraussetzungen konnte ein entsprechend berechtigter Administrationsbenutzer über manipulierte Dateiinformationen Dateien außerhalb des vorgesehenen Medienverzeichnisses speichern. Abhängig von der Serverkonfiguration konnte daraus sogar die Ausführung von PHP-Code und damit eine vollständige Übernahme des Shops entstehen.

Schutz gegen SSRF beim Medienimport

Der Import von Medien über externe URLs wurde ebenfalls abgesichert.

Bei einem SSRF-Angriff wird ein Server dazu gebracht, eine Netzwerkverbindung zu einem Ziel herzustellen, das für einen externen Angreifer selbst nicht erreichbar wäre. Besonders relevant sind dabei private Netzwerkbereiche, interne Dienste oder Infrastrukturkomponenten.

Shopware sendet den Medienimport nun an die Adresse, die bei der URL-Prüfung tatsächlich aufgelöst wurde, und überprüft alle aufgelösten Adressen statt nur der ersten IPv4-Adresse.

Eine Implementierung von FileUrlValidatorInterface kann eine URL weiterhin ablehnen, kann aber nicht mehr dazu führen, dass eine private oder reservierte Adresse trotz erfolgreicher Validierung angesprochen wird.

Wer bewusst Medien von einem Host in einem privaten oder reservierten Adressbereich importieren muss, kann die URL-Prüfung explizit über shopware.media.enable_url_validation deaktivieren. Eine solche Ausnahme sollte jedoch nur bewusst und mit Blick auf die konkrete Netzwerkinfrastruktur eingesetzt werden.

Webhooks: Zielprüfung vor jeder Anfrage und jedem Redirect

Eine vergleichbare Absicherung wurde für Webhooks umgesetzt.

Webhook-Ziele werden nun vor jeder ausgehenden Anfrage und vor jedem weitergeleiteten Redirect geprüft. Standardmäßig müssen Ziele HTTPS verwenden und ausschließlich auf öffentliche IP-Adressen auflösen. HTTP-Ziele, IP-Adressen als direkte Zielangabe sowie interne Netzwerkziele werden abgelehnt.

Ausnahmen können Betreiber gezielt über shopware.yaml konfigurieren, etwa mit shopware.app_system.allow_unencrypted_traffic oder shopware.app_system.allowed_private_ip_addresses.

Besonders technisch relevant ist dabei der Schutz gegen DNS-Rebinding: Shopware verwendet das bei der Validierung ermittelte DNS-Ergebnis auch für die tatsächliche HTTP-Verbindung. Dadurch wird das Zeitfenster reduziert, in dem sich die aufgelöste Adresse zwischen Prüfung und Verbindung verändern könnte.

Guest-Dokumente: Rate Limiting verhindert wiederholte Anmeldeversuche

Dokumente können in Shopware unter bestimmten Voraussetzungen über Gast-Links abgerufen werden. Für die Authentifizierung solcher Dokumenten-Downloads gibt es nun ebenfalls einen Rate Limiter.

Wiederholte ungültige Authentifizierungsversuche werden nach Erreichen des konfigurierten Limits abgewiesen. Eine erfolgreiche Authentifizierung setzt das Limit zurück.

Damit wird ein Angriffsweg erschwert, bei dem ein Angreifer beispielsweise eine bekannte Dokumenten-URL und eine E-Mail-Adresse besitzt und wiederholt mögliche zusätzliche Authentifizierungsinformationen ausprobiert.

Das ist insbesondere aus Datenschutzsicht relevant: Rechnungen, Lieferscheine und vergleichbare Dokumente können personenbezogene Kundendaten enthalten. Ein technisch funktionierender Dokumentenlink ist daher keineswegs gleichbedeutend mit einem ausreichenden Schutz der dahinterliegenden Informationen.

Elasticsearch und OpenSe arch: Automatischer Reindex bei Analyseänderungen

Neben den eigentlichen Sicherheitskorrekturen enthält Shopware 6.7.13.1 auch wichtige technische Verbesserungen.

Bei Elasticsearch beziehungsweise OpenSearch können Änderungen an Mapping und Analysekonfiguration miteinander zusammenhängen. Wenn ein Mapping beispielsweise auf einen Analyzer oder Normalizer verweist, den die Analysekonfiguration des aktuell verwendeten Index nicht enthält, kann die Aktualisierung des Mappings fehlschlagen.

Da Analyse-Einstellungen eines bestehenden Index nicht beliebig nachträglich ergänzt werden können, plant Shopware in diesem Fall nun automatisch einen Reindex ein. Die betroffene Entität wird in einen neu erzeugten Index mit den aktuellen Analyse-Einstellungen übertragen.

Für Shopbetreiber bedeutet das eine robustere Aktualisierung der Suchinfrastruktur und weniger Risiko, dass eine veraltete Mapping-Konfiguration im laufenden System zurückbleibt.

Dokumentenerstellung mit angepassten Twig-Umgebungen

Auch die Dokumentenerstellung wurde technisch verbessert.

Der Dokumentenrenderer erwartet nun die grundlegende Twig\Environment statt der spezifischen Shopware-TwigEnvironment. Dadurch können dekorierte Twig-Services verwendet werden, ohne dass die Dokumentenerstellung allein aufgrund dieser Anpassung fehlschlägt.

Bei Verwendung der Shopware-eigenen Twig-Umgebung greift weiterhin die Zeitzonenüberschreibung des jeweiligen Sales Channels. Wird dagegen eine dekorierte Umgebung eingesetzt, die nicht von dieser Shopware-Klasse erbt, verwendet die Dokumentenerstellung die Standardzeitzone von Twig.

Das ist insbesondere für individuell erweiterte Shopware-Installationen relevant, bei denen Plugins oder eigene Erweiterungen in die Template-Verarbeitung eingreifen.

Warum Sicherheitsupdates bei einem Onlineshop besonders wichtig sind

Die Bandbreite der behobenen Probleme macht deutlich, dass moderne Shopware-Systeme eine große Angriffsfläche besitzen können. Ein Onlineshop besteht nicht nur aus der Storefront. Hinzu kommen Administration, Store API, Admin API, Apps, Plugins, Medienverarbeitung, Dokumente, Suchserver und zahlreiche externe Integrationen.

Eine Sicherheitslücke muss deshalb nicht unmittelbar über die öffentlich sichtbare Shopseite ausnutzbar sein, um relevant zu werden. Ein Angreifer kann unter Umständen einen weniger geschützten Bestandteil als Einstiegspunkt verwenden und anschließend versuchen, seine Rechte auszuweiten oder weitere Systeme zu erreichen.

Besonders kritisch sind Schwachstellen, die zu Codeausführung, Rechteausweitung, SQL-Injection oder SSRF führen können. Ebenso wichtig ist der Schutz personenbezogener Daten. Ein erfolgreicher Zugriff auf Rechnungen, Lieferscheine, Kundeninformationen oder nicht veröffentlichte Inhalte kann neben technischen Folgen auch datenschutzrechtliche und wirtschaftliche Konsequenzen haben.

Sicherheitsupdates schließen bekannte Schwachstellen und reduzieren damit die Angriffsfläche. Sie ersetzen allerdings kein ganzheitliches Sicherheitskonzept. Dazu gehören unter anderem aktuelle Serverkomponenten, eine restriktive Rechtevergabe, sichere Zugangsdaten, regelmäßige Backups, eine kontrollierte Plugin- und App-Landschaft sowie eine Überprüfung individueller Konfigurationen.

Was Betreiber jetzt prüfen sollten

Wir empfehlen im Zusammenhang mit dem Update insbesondere folgende Punkte:

• Backup erstellen: Vor dem Update sollte eine aktuelle und getestete Sicherung von Datenbank und relevanten Dateien vorhanden sein.
• APP_URL kontrollieren: Die Konfiguration sollte die tatsächlich öffentliche HTTP- oder HTTPS-Adresse des Shops enthalten.
• Benutzerrechte überprüfen: Nicht mehr benötigte Administrationskonten und weitreichende Berechtigungen sollten regelmäßig kontrolliert werden.
• Apps und Plugins prüfen: Erweiterungen sollten auf aktuelle und mit der eingesetzten Shopware-Version kompatible Stände gebracht werden.
• Individuelle Integrationen testen: Insbesondere Integrationen, die Store-API-Criteria, Medienimporte, Webhooks oder sehr komplexe Criteria-Strukturen verwenden, sollten nach dem Update getestet werden.
• Private Netzwerkziele bewusst konfigurieren: Ausnahmen für Medienimporte oder Webhooks sollten nur eingerichtet werden, wenn sie tatsächlich benötigt werden.
• Suchindex kontrollieren: Nach dem Update sollte insbesondere bei Elasticsearch- oder OpenSearch-Systemen geprüft werden, ob Reindexierungen erfolgreich abgeschlossen wurden.