Shopware-Security-Updates: Warum du nicht auf das Advisory warten darfst

Was am 16. September passiert ist

Dienstagmorgen, 08:14 Uhr: Shopware veröffentlicht 6.7.14.1 und 6.6.10.25. Beide im Changelog als „Security Update" markiert, beide ohne Feature-Anteil. Das 6.7er-Release kam damit genau eine Woche nach dem Feature-Release 6.7.14.0 vom 09.09.

Wer an dem Morgen wissen wollte, was genau gepatcht wurde, fand: nichts. Die GitHub Security Advisories zeigten als jüngste Einträge die vom 25. August. Zwischen „hier ist ein Security-Patch" und „das stand drin" lag eine Lücke.

Inzwischen sind die Advisories da — fünf Stück, alle auf den 16.09. datiert. Genau dieses Muster ist das Thema: Der Patch kommt zuerst, die Beschreibung kommt nach. Das ist kein Versehen, sondern Absicht. Und es hat eine Konsequenz für deinen Update-Prozess, die viele genau falsch herum ziehen.

Die fünf Lücken, jetzt mit Namen

Zwei Dinge daran sind für die Risikoeinschätzung wichtiger als die Zahlen.

Die 8,6er trifft auch Shops ohne Admin-Zugang von außen. Sie braucht keinen Login, nur einen gültigen Sales-Channel-Access-Key — den hat jede Storefront. Die Bedingung PDO::ATTR_EMULATE_PREPARES ist bei PHP-Installationen unterhalb 8.4 der verbreitete Standard. Wer noch auf PHP 8.2 oder 8.3 läuft — und das ist im 6.6er-Feld die Mehrheit — ist mit hoher Wahrscheinlichkeit betroffen.

Die 9,6er und die 8,1er setzen einen Innentäter oder eine gekaperte Sitzung voraus. Das klingt beruhigender, als es ist: Sie sind genau die Werkzeuge, mit denen aus einem kleinen Zugang ein großer wird. Ein kompromittierter Redaktions-Account mit Webhook-Recht wird über GHSA-r432 zum Datenabfluss inklusive Wiederherstellungs-Tokens.

Alle fünf sind in 6.7.14.1 und 6.6.10.25 behoben. Betroffen sind 6.7.0.0 bis 6.7.14.0 sowie alles unterhalb 6.6.10.25 — das schließt 6.5 und älter ausdrücklich ein.

Der Ablauf: Patch → Advisory → Exploit

So läuft es bei Shopware regelmäßig ab, und es lohnt sich, die drei Phasen sauber auseinanderzuhalten.

Phase 1 — der Patch. Die Version erscheint, im Changelog steht „Security Update". Mehr nicht. Kein Advisory, keine Scores, keine Beschreibung. Der Gedanke dahinter ist naheliegend: Solange niemand weiß, wo das Loch war, ist die Wahrscheinlichkeit geringer, dass es jemand findet, bevor die Shops gepatcht sind.

Phase 2 — das Advisory. Stunden bis Wochen später erscheint die Beschreibung mit CVSS, betroffenen Versionen und Mitigation. Ab diesem Moment weiß auch die Gegenseite, wonach sie sucht.

Phase 3 — der Exploit. Der öffentliche Proof of Concept, das Scanner-Modul, die automatisierte Massenausnutzung.

Der entscheidende Punkt, den viele Betreiber übersehen: Phase 1 ist nicht wirklich geheim. Shopware ist Open Source. Der Commit, der die Lücke schließt, liegt ab dem Release öffentlich auf GitHub. Wer die Diffs eines Security-Releases liest, hat die Schwachstelle — egal, ob das Advisory schon existiert. Das ist keine theoretische Möglichkeit, sondern eine etablierte Disziplin; „Patch Diffing" ist die Standardmethode, aus einem Fix einen Exploit zu bauen.

Das Zurückhalten des Advisories verschafft dir also Stunden, keine Wochen. Und es verschafft sie dir nur, wenn du sie auch nutzt.

Warum „ich warte auf das Advisory" die falsche Schlussfolgerung ist

Das Argument klingt vernünftig: Ich weiß ja nicht, was drin ist. Vielleicht betrifft es mich gar nicht. Ich warte, bis ich einschätzen kann, wie dringend das ist.

Der Denkfehler steckt in der Annahme, Warten sei ein neutraler Zustand. Ist es nicht. Während du wartest,

• ist die Lücke in deinem Shop offen,
• ist der Fix öffentlich lesbar,
• und du bist nicht informierter geworden, sondern nur später dran.

Die Information, auf die du wartest, ändert an der Handlung nichts. Bei einem als „Security" markierten Shopware-Release lautet die Antwort in praktisch jedem Fall: updaten. Es gibt keine realistische Advisory-Formulierung, nach der du sagst „ach dann eben nicht". Selbst die harmloseste der fünf Lücken oben — der Double-Opt-in-Bypass mit 5,3 — ist in Deutschland kein Schönheitsfehler, sondern ein Einwilligungsproblem mit Abmahnpotenzial.

Anders gesagt: Du wartest auf eine Begründung für eine Entscheidung, die schon feststeht.

Dass das kein Papiertiger ist

Am 25. August hat Shopware mit 6.7.13.1 und 6.6.10.23 zehn Lücken geschlossen, darunter drei kritische:

Neun Tage später, am 3. September, meldete ein Hoster, dass mehrere selbst gehostete Shops erfolgreich kompromittiert wurden. Der Verdacht richtete sich auf eine der am 25.08. geschlossenen Lücken; der genaue Angriffsweg war zu dem Zeitpunkt nicht bestätigt.

Neun Tage. Das ist das Zeitfenster, über das wir reden — nicht Monate.

Und daran hängt der unangenehmste Satz dieses Beitrags: Ein Update schließt die Lücke, es beseitigt keine Kompromittierung. Wer den 25.08.-Patch erst im September eingespielt hat, hat nicht nur ein Update zu erledigen, sondern eine Prüfung.

Der Teil, den Security-Fans ungern erwähnen: Patches sind nicht folgenlos

Wer Betreibern erzählt, Security-Updates seien risikolos, war noch nie am Freitagabend im Rollback. 6.7.14.1 ist ein gutes Beispiel, warum die Angst vor dem Update nicht aus der Luft gegriffen ist. In diesem als reines Security-Release ausgewiesenen Patch stecken zwei Verhaltensänderungen:

Das Klonen von Benutzern und Integrationen über die Admin API ist abgeschaltet. Die entsprechenden Endpunkte antworten jetzt mit 403. Das ist die Konsequenz aus GHSA-p589 — man hat nicht die Rechteprüfung nachgebaut, sondern die Funktion entfernt. Wenn irgendein Skript, Deployment-Schritt oder Onboarding-Automatismus bei euch Benutzer per Clone-Endpunkt anlegt, ist der ab diesem Patch kaputt. Lautlos, mit einem 403, mitten in einem Nacht-Job.

Self-Service-Profilaktualisierungen akzeptieren nur noch Avatar-Medien in einem eng definierten Format. Auch das ist eine Verschärfung, die eine Integration treffen kann, die Profilbilder pflegt.

Das ist die ehrliche Version: Ein Security-Patch kann dir etwas wegnehmen. Genau deshalb braucht es einen Prozess — nicht, um langsamer zu sein, sondern um schnell sein zu können, ohne zu raten.

Der Update-Workflow aus Betreibersicht

Das Ziel ist nicht „Update innerhalb von 24 Stunden" als Selbstzweck. Das Ziel ist, dass ein Security-Update ein Routinevorgang von zwei Stunden ist und kein Projekt. Dann erledigt man es auch am selben Tag.

Vorher, einmalig: die Voraussetzungen schaffen

Wer diese vier Dinge nicht hat, wird jedes Security-Update als Krise erleben.

1. Ein Staging, das dem Live-Shop gleicht. Gleiche PHP-Version, gleiche Plugins in gleichen Versionen, aktueller Datenbank-Abzug. Ein Staging mit anderer Plugin-Konstellation beantwortet die einzige Frage nicht, die zählt.
2. Deployment über Composer, nicht über den Web-Updater. Nur so ist der Zustand reproduzierbar und ein Rollback mehr als eine Hoffnung.
3. Ein Datenbank-Backup, das ihr schon einmal zurückgespielt habt. Ein ungetestetes Backup ist eine Behauptung.
4. Eine Liste der Plugins mit Bezugsquelle und Verantwortlichem. Die Frage „wer kann dieses Plugin anpassen?" darf nicht erst im Störungsfall gestellt werden.

Der Ablauf am Update-Tag

Schritt 1 — Was steht an? Changelog prüfen, ob euer Zweig betroffen ist. Für die 6.6er-Linie ist es 6.6.10.25, für die 6.7er-Linie 6.7.14.1.

Schritt 2 — Auf Staging einspielen.

# Version festnageln statt "latest" ziehen
composer require shopware/core:6.7.14.1 --update-with-all-dependencies
bin/console system:update:finish
bin/console cache:clear

Bei 6.6 entsprechend shopware/core:6.6.10.25. Falls ihr noch die Meta-Pakete shopware/administration, shopware/storefront und shopware/elasticsearch separat führt, müssen die auf dieselbe Version.

Schritt 3 — Plugin-Kompatibilität prüfen.

bin/console plugin:refresh
bin/console plugin:list

Ein Patch-Release innerhalb derselben Minor-Version bricht selten eine Plugin-Schnittstelle — das ist der Grund, warum Security-Patches als reine Patch-Versionen ausgeliefert werden. „Selten" ist aber nicht „nie", und die 403-Änderung oben zeigt, dass der Bruch nicht in der Plugin-API stecken muss, sondern in einem Endpunkt, den euer eigenes Skript benutzt.

Schritt 4 — Den Rauchtest fahren. Nicht die Startseite aufrufen und zufrieden sein. Die vier Wege, die Geld kosten, wenn sie kaputt sind:

• Bestellung mit der real genutzten Zahlungsart bis zur Bestätigung,
• Login und Registrierung eines Kunden,
• der ERP- oder Warenwirtschafts-Abgleich (mindestens ein Lauf),
• alles, was per Admin API von außen an den Shop geht — eure n8n-Workflows, Export-Skripte, Onboarding-Automatismen. Genau hier landet die 403.

Schritt 5 — Live, mit Fluchtweg. Wartungsmodus, Backup direkt vorher, deployen, gleicher Rauchtest.

Der Rollback

Das Backup ist die zweite Verteidigungslinie, nicht die erste. Die erste ist ein Deployment, das den Vorzustand noch vorhält:

# Code zurück auf den vorherigen Stand
git checkout <letzter-tag> && composer install
bin/console cache:clear

Der Haken, den man kennen muss: Datenbank-Migrationen laufen nicht rückwärts. system:update:finish führt Migrationen aus, und Shopware liefert keine Down-Migrationen. Ein Code-Rollback nach einem Update ist deshalb nur dann sauber, wenn die Datenbank mit zurückgeht. Praktisch heißt das: Backup unmittelbar vor dem Live-Deployment, nicht das von heute Nacht — sonst kostet der Rollback die Bestellungen des Tages.

Bei einem Patch-Release ist der Migrationsumfang klein bis leer. Aber „klein" ist kein Zustand, auf den man ein Rollback plant.

Das Security-Plugin: Sicherheitsgurt, kein Ersatz für die Bremse

Shopware pflegt ein kostenloses Plugin, das Sicherheitsfixes in bestehende Installationen zurückportiert: SwagPlatformSecurity. Es ist das am meisten missverstandene Werkzeug in diesem ganzen Themenfeld, deshalb zuerst die Abgrenzung, die alles entscheidet.

Es schließt keine Lücken vorab. Das Plugin enthält ausschließlich Backports bereits veröffentlichter Advisories; jeder Fix darin hängt an einer konkreten GHSA-ID und an einem Versionsbereich. Es überbrückt also den Abstand zwischen „der Core-Fix existiert" und „mein Shop ist aktualisiert" — nicht den zwischen „die Lücke existiert" und „jemand hat sie gefunden". Gegen das, was morgen entdeckt wird, hilft es heute nicht. Das kann kein Werkzeug.

Vorab installieren solltest du es trotzdem. Die Fixes sind versionsgesteuert: Enthält deine Shopware-Version den offiziellen Patch bereits oder liegt sie unterhalb der ersten betroffenen Version, bleibt der Fix inaktiv. Das Plugin auf einem topaktuellen Shop zu installieren ist damit folgenlos — es schläft. Und genau deshalb gehört es vor die Krise, nicht in sie hinein: Beim nächsten Security-Release hast du dann zwei Hebel statt einem.

Wie gut das im Ernstfall greift, zeigt genau dieses Release: Plugin-Version 4.0.15 erschien am 16.09.2026 — am selben Tag wie 6.7.14.1 und 6.6.10.25, mit allen fünf Fixes. Wer das Plugin installiert hatte, war am Dienstagvormittag versorgt und konnte das Core-Update in Ruhe ins reguläre Fenster legen. Wer es an dem Morgen erst entdeckte, hat den Tag mit Store-Login und Kompatibilitätsfragen verbracht.

Der Haken, den man vorher wissen muss

Das Plugin rettet dich nicht vor der Verhaltensänderung. Im Changelog von 4.0.15 steht dieselbe Zeile wie im Core: Das Klonen von User- und Integration-Datensätzen über die Admin API wird mit 403 abgelehnt, und Profil-Updates akzeptieren nur noch Avatar-Referenzen.

Das ist auch logisch — der Fix ist die Einschränkung. Wer gehofft hatte, das Plugin sei der schmerzfreie Weg um einen brechenden Patch herum: ist es nicht. Der Rauchtest über eure API-Integrationen fällt nicht weg, er verschiebt sich nur nach vorn.

Drei Grenzen

Abhängigkeiten sind nicht abgedeckt. Lücken in Symfony, Twig und dem restlichen Unterbau bleiben offen. composer audit gehört weiter in den Ablauf, und was dort auftaucht, braucht ein echtes Update.

Shopware sagt selbst, dass es nicht immer vollständig geht. In der Dokumentation steht sinngemäß, dass sich eine Lücke nicht in jedem Fall für jede betroffene Version sicher oder vollständig über das Plugin schließen lässt. Ein stiller Teilfix ist also möglich.

Ein Backport ist eine Neuimplementierung — und die kann falsch sein. Dafür gibt es einen dokumentierten Fall: CVE-2025-27892. Plugin-Version 2.0.10 sollte eine SQL-Injection im aggregations-Parameter der API schließen, bereinigte aber nur das oberste name-Feld und übersah verschachtelte Aggregationen. Shops mit installiertem Plugin hielten sich für geschützt und waren es nicht. Behoben erst in 2.0.11.

Weniger dramatisch, im Alltag aber ärgerlich: Die Versionssteuerung greift nicht überall gleich zuverlässig. Für Overrides in der Administration fehlt sie (Issue #18303) — ein Override bleibt nach dem Core-Fix aktiv und reicht nicht per $super weiter, wodurch andere Plugins auf derselben Komponente lautlos ausgehebelt werden.

Installation

composer require store.shopware.com/swagplatformsecurity

Oder über den Extension Store in der Administration; beides setzt einen Shopware-Account voraus. Die Zweige sind nach Shopware-Generation getrennt: 4.x → 6.7, 3.x → 6.6, 2.x → 6.5. Der 1.x-Zweig für 6.4 wird nicht mehr gepflegt.

Eine Verwechslung, die im Store leicht passiert: Es gibt ein gleichnamiges Security-Plugin für Shopware 5 (Stand 1.1.40 von Juli 2023). Das ist ein anderes Produkt und für 6.x wirkungslos.

Kurzfassung: installieren, solange nichts brennt. Beim Security-Release am selben Tag das Plugin aktualisieren, das Core-Update planmäßig hinterher. Was nicht funktioniert, ist dauerhaft auf dem Plugin stehen zu bleiben — 6.6 ist nur noch in Extended Support, und die Abhängigkeitslücke bleibt offen.

Wenn ihr wirklich nicht updaten könnt

Es gibt Fälle, in denen das Update nicht am selben Tag geht: Eine Individualentwicklung hängt an einem internen Verhalten, ein Plugin-Hersteller ist noch nicht nachgezogen, das Release-Fenster ist hart. Dann ist die Antwort nicht „abwarten", sondern „überbrücken" — mit dem Plugin aus dem vorigen Abschnitt und mit den Mitigationen, die Shopware in den Advisories selbst nennt. Für dieses Release sind sie ungewöhnlich handfest:

Die PHP-8.4-Zeile verdient einen eigenen Gedanken: Sie schließt nicht nur diese eine Lücke, sondern eine ganze Klasse. Wer noch auf 8.2 oder 8.3 steht, hat hier ein Argument, das über dieses Release hinaus trägt.

Und dann die eigentliche Aufgabe: Wenn ein Plugin euch dauerhaft davon abhält, Security-Updates zeitnah einzuspielen, ist das keine technische Randnotiz mehr. Das ist eine Entscheidung darüber, welches Risiko dieses Plugin wert ist — und die gehört auf den Tisch, nicht ins Ticket-Backlog.

Nach dem Update: die Frage, die niemand stellen will

Wenn zwischen Patch und Einspielen mehr als ein paar Tage lagen, ist die ehrliche nächste Frage nicht „läuft alles?", sondern „war jemand drin?". Vier Dinge, die sich in einer halben Stunde prüfen lassen:

1. Admin-Benutzer durchsehen. Unbekannte Konten? Konten, die unerwartet Administratorrechte haben? Beide Lücken oben mit 8,1 und 6,5 enden genau dort.
2. Integrationen und deren Rollen prüfen. Eine angelegte Integration ist ein dauerhafter API-Zugang, der einen Passwortwechsel überlebt.
3. Webhook-Registrierungen durchsehen. GHSA-r432 dreht sich genau darum: Webhooks, die Daten jenseits ihrer Berechtigung bekamen. Ein Webhook, der auf eine fremde Domain zeigt, ist kein Konfigurationsfehler.
4. Dateisystem auf Neues prüfen — vor allem in public/ und den Plugin-Verzeichnissen. Ein Pfad-Traversal-Fehler wie der vom 25.08. endet in einer abgelegten Datei, die einen Neustart überlebt.

Und wenn dabei etwas auffällt: Admin-Passwörter zurücksetzen, App-Secrets und Integrations-Zugänge rotieren, Wiederherstellungs-Tokens für ungültig erklären. Das empfiehlt Shopware für die Webhook-Lücke ausdrücklich.

Fazit

Der Ablauf wiederholt sich alle paar Wochen, und er wird sich wieder wiederholen. Deshalb drei Sätze zum Mitnehmen:

Das fehlende Advisory ist kein Grund zu warten — es ist der Grund, schnell zu sein. Der Fix liegt ab Sekunde eins öffentlich auf GitHub. Die Schonfrist, die dir das zurückgehaltene Advisory verschafft, misst sich in Stunden, und sie läuft für dich und den Angreifer gleichzeitig.

Die Angst vor Plugin-Bruch ist berechtigt — die Schlussfolgerung daraus ist falsch. Nicht „später updaten", sondern den Update-Vorgang so billig machen, dass er nicht wehtut: Staging mit gleichem Stand, Composer statt Web-Updater, getestetes Backup, ein Rauchtest über die vier Wege, die Geld kosten. Wer das hat, spielt einen Security-Patch am selben Tag ein und geht abends nach Hause.

Und wer ein 6.6er-Feld betreibt, hat gerade ein gutes Argument in der Hand. 6.6.10.25 ist da, die Lücken betreffen 6.6 genauso wie 6.7, und die schwerwiegendste braucht nicht einmal einen Login. Das ist ein besserer Anlass für das lange aufgeschobene Gespräch über Update-Fähigkeit als jedes Feature-Release.

Wenn ihr so einen Update-Prozess für euren Shop aufsetzen wollt — Staging, Deployment, Rauchtest, Rollback — und das lieber einmal richtig macht, statt beim nächsten Security-Release wieder zu improvisieren: Meldet euch.