Shopware 6.7.13.1 Sicherheitsupdate: Warum Sie jetzt handeln sollten

Ein Update, das nicht im nächsten Sprint warten sollte

Am 25. August 2026 hat Shopware mit Version 6.7.13.1 ein Sicherheitsupdate veröffentlicht, das neun Schwachstellen schließt. Drei davon stuft Shopware selbst als kritisch ein, die schwerste mit einem CVSS-Wert von 9,6. Für die 6.6er-Reihe zog Shopware einen Tag später mit 6.6.10.23 nach, das Update schließt dieselben neun Lücken.

Für Agenturen mit mehreren betreuten Shops ist das ein Update, das sich schnell zwischen anderen Terminen verliert. Genau das ist das eigentliche Risiko dabei, nicht die technische Komplexität des Updates selbst.

Die drei kritischen Lücken im Detail

Alle drei kritischen Schwachstellen hängen mit dem App-System zusammen, entweder direkt oder über den Umweg der Administrator-Rechte.

Ausbruch aus der App-Sandbox, CVSS 9,6. Eine bösartige oder übernommene App konnte die Ausführungsbeschränkungen der App Scripts umgehen und beliebige PHP-Funktionen sowie Betriebssystem-Befehle ausführen. Damit waren laut Shopware Zugriff auf Konfiguration und Zugangsdaten, Dateiänderungen und der Zugriff auf interne Dienste möglich. Der Filter find sowie die Operatoren has some und has every weisen jetzt Zeichenketten-Callables ab, die nicht ausdrücklich freigegeben sind.

Übernahme von Administrator-Konten, CVSS 9,3. Der Ablauf zum Zurücksetzen des Administrator-Passworts prüfte den verwendeten Host nicht ausreichend. Ein Angreifer ohne eigene Zugangsdaten konnte den Link in der Wiederherstellungs-Mail auf eine eigene Adresse lenken, in der Hoffnung, dass ein Administrator ihn anklickt. Der Link wird jetzt aus der konfigurierten APP_URL gebildet statt aus der jeweiligen Anfrage.

SQL-Injection über Feldnamen aus App-Manifesten, CVSS 9,1. Namen aus eigenen Entitätsdefinitionen wurden nicht ausreichend geprüft, bevor daraus Tabellen und Spalten wurden. Eine App konnte darüber beliebiges SQL mit den Rechten der Datenbankverbindung ausführen. Entitäts- und Feldnamen werden bei Installation und Update jetzt validiert.

Was Sie vor dem Update konkret prüfen sollten

Neben den reinen Sicherheitsfixes ändert das Update drei Verhaltensweisen, die bestehende Integrationen betreffen können.

Webhooks an andere Systeme verschickt Shopware jetzt nur noch verschlüsselt und nur an öffentlich erreichbare Adressen. Verbindungen zu internen Systemen oder unverschlüsselten Zielen brechen nach dem Update ab, solange sie nicht ausdrücklich freigegeben wurden, etwa über shopware.app_system.allow_unencrypted_traffic in der shopware.yaml. Betroffen sind vor allem eigene Apps und direkt angebundene interne Systeme, seltener Erweiterungen aus dem Shopware Store.

Der bereits erwähnte Passwort-Reset-Link wird jetzt aus der konfigurierten Shop-Adresse gebildet. Steht dort nicht die tatsächliche öffentliche Adresse des Shops, führt der Link ins Leere. Das lässt sich vor dem Update in wenigen Minuten in der Konfiguration prüfen.

Eigene Template-Anpassungen können betroffen sein, wenn ein Theme oder Plugin die genannten Twig-Filter und -Operatoren mit einem Funktionsnamen als Zeichenkette nutzt statt mit einer Pfeilfunktion. Das dürfte nur wenige Shops betreffen, lässt sich aber vorab schnell durchsuchen.

Warum dieses Update gerade Agenturen ohne Wartungsvertrag betrifft

Ein Sicherheitsupdate dieser Kategorie ist technisch überschaubar. Backup erstellen, in Staging testen, Cache und Index neu aufbauen, die drei genannten Punkte prüfen, dann live gehen. Der eigentliche Engpass liegt selten in der technischen Umsetzung, sondern darin, dass überhaupt jemand die Verantwortung dafür trägt, das Update zeitnah einzuspielen.

Bei Shops mit laufender Wartungsvereinbarung ist diese Verantwortung klar zugeordnet, das Update landet automatisch im nächsten Wartungsfenster. Bei Projekten ohne laufende Betreuung bleibt die Frage dagegen offen, wer überhaupt informiert wird, wenn Shopware ein Advisory veröffentlicht. Genau dort entsteht die Lücke zwischen Release und tatsächlichem Update, nicht bei der technischen Komplexität des Patches selbst.

Ein ehrlicher Punkt dazu: Nicht jeder Shop braucht deshalb sofort eine formale Wartungsvereinbarung. Wer selbst regelmäßig die Shopware-Security-Advisories verfolgt und intern eine klare Zuständigkeit für Updates hat, kommt auch ohne festen Vertrag zuverlässig durch solche Releases. Entscheidend ist weniger die Vertragsform als die Frage, ob diese Verantwortung tatsächlich irgendwo verankert ist.

Was das für Ihre nächsten Schritte bedeutet

Bei drei kritischen Einstufungen und einer SQL-Injection, die teilweise ohne fremde Zugangsdaten auskommt, gehört dieses Update in ein zeitnahes Wartungsfenster, nicht in die nächste ohnehin geplante Iteration. Wichtiger als die technische Umsetzung selbst ist die Frage, ob für Ihre Shopware-Installation überhaupt geklärt ist, wer solche Advisories verfolgt und wer sie einspielt.

Diese Klärung lohnt sich unabhängig vom aktuellen Update, weil das nächste Security-Release mit Sicherheit kommt.

Dennis Schwenker-Sanders ist PHP-, Symfony- und Shopware-Entwickler und begleitet Agenturen und KMU im DACH-Raum bei Wartung und Sicherheitsstrategie ihrer Shopware-Installationen. Mehr zu meiner Arbeit rund um Symfony und PHP finden Sie auf der Leistungsseite.