Shopware Security Update September 2026

Fünf Lücken geschlossen, eine davon kritisch

Shopware hat am 16. September 2026 die Versionen 6.7.14.1 und 6.6.10.25 veröffentlicht. Beide sind reine Sicherheits-Releases: Sie schließen fünf Schwachstellen, die Shopware zeitgleich als GitHub-Advisories dokumentiert hat. Eine davon ist als kritisch eingestuft, zwei als hoch, zwei als mittel. Anders als beim umfangreichen Sammelupdate von Ende August, zu dem später Berichte über kompromittierte Shops hinzukamen, gibt es diesmal keine Meldung über aktiv ausgenutzte Lücken. Ein zeitnahes Einspielen bleibt trotzdem angeraten, besonders wegen des kritischen Befunds.

Zum Nachlesen: das vollständige Original-Changelog auf GitHub und die einzelnen Security-Advisories mit den Details und der CVSS-Einstufung je Lücke.

Der rote Faden: Daten sollen den Shop nicht verlassen

Die meisten Fixes dieses Releases drehen sich um dieselbe Frage: Welche Informationen darf ein Shop nach außen geben, und an wen. Webhooks sind die automatischen Benachrichtigungen, mit denen Shopware angebundene Dienste über Ereignisse informiert, etwa eine neue Registrierung oder eine ausgelöste Passwort-vergessen-Anfrage.

Die kritische Lücke steckt genau dort. Über eine Webhook-Berechtigung ließen sich die Zugriffsregeln eines Ereignisses umgehen, sodass sensible Daten in einer Benachrichtigung landeten, die dort nicht hingehören. Shopware zieht daraus mehrere Konsequenzen: Die Ereignisse für Passwort-Wiederherstellung und internen Mailversand werden gar nicht mehr an Webhooks ausgeliefert, und aus den übrigen Payloads verschwinden das Session-Token einer Kunden-Anmeldung, die Bestätigungslinks aus Double-Opt-In-Registrierungen und der Bestätigungs-Hash aus der Kundenregistrierung. In Flow Builder, den shopeigenen Wenn-dann-Abläufen, bleiben all diese Werte weiter verfügbar; geschlossen ist nur der Weg nach außen über Webhooks.

Für Entwickler mit eigenen Apps heißt das: Ein Ereignis meldet sich mit dem neuen Attribut #[NotHookable] von der Webhook-Auslieferung ab, und ein einzelner Wert bleibt mit EventDataCollection::HIDDEN_FROM_WEBHOOK => true aus dem Payload heraus. App-Manifeste, die die entfernten Ereignisse abonnieren, funktionieren bis 6.8 weiter, lösen aber eine Deprecation-Warnung aus.

Die weiteren Lücken im Überblick

Neben dem kritischen Webhook-Befund schließen die Releases vier weitere Schwachstellen, jeweils mit Link auf das offizielle Advisory.

Hoch

• Rechteausweitung über Profil-Updates: Die Route, über die ein angemeldeter Nutzer sein eigenes Profil ändert (PATCH /api/_info/me), akzeptierte im Feld avatarMedia beliebige Inhalte. Jetzt ist nur noch der Verweis auf eine Medien-ID in der Form {"id": "<media-id>"} erlaubt, alles andere wird mit einem 403 abgewiesen.
• SQL-Injection in der Store-API-Aggregation: Über die Namen von Aggregationen, also von Auswertungsabfragen der Store API (dem Schnittstellen-Zugang der Storefront), ließen sich auf PHP-Versionen vor 8.4 Datenbankbefehle einschleusen. Aggregationsnamen mit Backtick, Fragezeichen, Doppelpunkt oder Steuerzeichen werden nun abgewiesen.

Mittel

• Rechteausweitung über das Klonen von Objekten: Benutzer- und Integrationskonten ließen sich über die Admin API mit unzureichender Rechteprüfung duplizieren. Die entsprechenden Klon-Routen liefern jetzt einen 403 und sind damit deaktiviert.
• Umgehung des Newsletter-Double-Opt-In: Die Newsletter-Aktivierung erzwingt jetzt konsequent das konfigurierte Double-Opt-In, also die ausdrückliche Bestätigung per Mail, bevor eine Adresse als Abonnent gilt.

Was jetzt zu tun ist

Die gute Nachricht: Beide Releases sind Patch-Versionen innerhalb ihres Zweigs. Wer Shopware 6.7 nutzt, aktualisiert auf 6.7.14.1, wer auf 6.6 steht, auf 6.6.10.25. Solche Updates an der vierten Stelle der Version ändern keine Schnittstellen und keine Template-Strukturen, das Risiko für Plugins und Themes ist entsprechend gering. Trotzdem gilt wie bei jedem Update: vorher ein vollständiges Backup von Datenbank und Dateien, danach die Caches leeren und die wichtigsten Abläufe im Shop einmal durchklicken. Wer PHP in einer Version vor 8.4 einsetzt, hat mit dem SQL-Injection-Befund einen zusätzlichen Grund, das Update nicht aufzuschieben.

Das Sicherheits-Plugin als zweiter Weg

Wer nicht sofort auf die neue Patch-Version aktualisieren kann, hat eine zweite Möglichkeit: Shopware pflegt ein kostenloses Sicherheits-Plugin, das die Fixes in eine bestehende Installation zurückportiert, ohne dass Shopware selbst aktualisiert werden muss. Ein Plugin-Update schließt damit die Lücken, das eigentliche Versionsupdate kann geplant folgen.

Das Plugin gibt es für alle aktuell unterstützten Zweige: die Reihe 4.x für Shopware 6.7, 3.x für 6.6 und 2.x für 6.5. Für 6.5-Shops ist es sogar der einzige Weg, denn für diesen Zweig gibt es kein Patch-Release. Zwei Punkte gehören zur ehrlichen Einordnung, beide von Shopware selbst so benannt: Das Plugin ist zur Überbrückung gedacht und kein Ersatz für reguläre Updates, und es deckt keine Sicherheitsprobleme in Drittanbieter-Bibliotheken wie Symfony oder Twig ab. Nur wer noch auf 6.4 oder älter läuft, bleibt außen vor, denn für diese Zweige wird auch das Plugin nicht mehr gepflegt; hier führt der belastbare Weg über das Update auf einen aktuellen Versionszweig, bei dem die Wartung unterstützt.

Kurz einplanen, nicht liegen lassen

Ohne aktiv ausgenutzte Lücke besteht diesmal kein Grund zur Hektik, wohl aber einer, das Update in den nächsten Tagen fest einzuplanen. Größere Shops testen den Patch sinnvollerweise zuerst auf einem Staging-System, dem Testklon des Shops, bevor er live geht. In der Praxis scheitert so ein Update selten an der Technik, sondern an der Zuständigkeit: Der Shop läuft, niemand liest Security-Advisories, und die Agentur von damals ist nicht mehr an Bord. Genau dafür gehört zu den Wartungspaketen auf der Shopware-Seite ein regelmäßiger Update-Check, der neue Shopware- und Plugin-Versionen erkennt, bewertet und einplant, bevor aus einer Lücke ein Vorfall wird.