Shopware 6.5: Sicherheitsupdates enden im Februar 2027

Für Shopware 6.5 läuft eine Frist, die man als Text kaum findet: Laut Release-Kalender von Shopware erhält die Reihe nur noch bis Ende Februar 2027 Sicherheitsfixes, und die kommen seit Juni 2025 grundsätzlich nicht mehr als Patch-Release, sondern über das Security-Plugin (Shopware-Release-Kalender). Das Plugin schließt Lücken im Code von Shopware, aber keine in Symfony oder Twig (Shopware-Doku Security Plugin). Wie eng der Rahmen geworden ist, zeigten die Sicherheitsreleases im August und September 2026: Kernpatches gab es nur noch für 6.6 und 6.7. Dieser Beitrag ordnet das Datum ein, zeigt, was das Plugin leistet und was nicht, und beschreibt einen Fahrplan, mit dem ein Shop bis Ende Februar 2027 auf Shopware 6.7 umsteigt. Für die Umsetzung steht unsere Shopware-Agentur bereit.

Was der Release-Kalender für Shopware 6.5 zeigt

Shopware veröffentlicht seine Supportzusagen nicht als Liste mit Daten, sondern als Grafik auf der Seite mit der Release Policy. Die Seite beschreibt vier Zustände: gepflegte Version, Extended Support, nur Sicherheitsfixes und Lebensende. Für den Zustand „Security fixes only“ legt Shopware fest, dass die Korrekturen über ein Security-Plugin kommen und nicht als direktes Patch-Update (Shopware-Release-Kalender). In genau diesem Zustand steht die letzte Minor-Version 6.5.8.0 mit ihren Patch-Ständen. Für ältere 6.5-Minor-Versionen zeigt die Grafik schon seit Mai 2025 keinen Balken mehr (Shopware-Release-Kalender); wer dort noch steht, braucht ohnehin zuerst das Update auf 6.5.8.19.

Ein Enddatum steht nirgends als Text. Wir haben die Balken der Grafik am 05.10.2026 ausgemessen: Der Abschnitt „Security fixes only“ für 6.5.8.0 endet am 28.02.2027 (Shopware-Release-Kalender). Dasselbe Datum führt das offene Verzeichnis endoflife.date als Ende der Sicherheitsversorgung für 6.5 (endoflife.date). Zwei Wege, ein Ergebnis: Das reicht als Planungsgrundlage, ist aber keine schriftliche Zusage.

Dazu passt ein Satz, den Shopware unter die Grafik gestellt hat: Übergänge zwischen den Supportphasen hängen an Hauptversionen, nicht an festen Zeiträumen (Shopware Release Policy). Was das für 6.6 und 6.7 bedeutet, beschreibt der Beitrag Shopware 6.8 für 2027 angekündigt. Für 6.5 ist der Kalender trotzdem die einzige veröffentlichte Angabe, und sie unterscheidet sich in einem Punkt grundsätzlich von den neueren Reihen: 6.5 bekommt keine Kernpatches mehr, sondern nur noch Korrekturen über das Plugin.

Wie Shopware 6.5 bis hierher versorgt wurde

Shopware 6.5 erschien am 03.05.2023 (endoflife.date). Mit 6.6.0.0 führte Shopware im März 2024 eine neue Release Policy ein, die Hauptversionen bis zu zwei Jahre Unterstützung zusagte, beginnend mit 6.5 (Shopware-Release-Notes 6.6.0.0). Die Reihe 6.5 wechselte damit in den Extended Support und erhielt weiter Patch-Releases. Mit der stabilen Version 6.7.0.0 vom 17.06.2025 endete dieser Abschnitt: Seitdem gibt es für 6.5 keine erweiterte Wartung mehr, und 6.6 übernahm die Rolle der Version im Extended Support (Shopware-Release-Notes 6.7.0.0).

Angekündigt hatte Shopware das schon vorher. Zu 6.5.8.18 vom 12.05.2025 heißt es in den Release Notes, dies werde der letzte Patch für die Reihe 6.5 sein, verbunden mit der Aufforderung, das Security-Plugin zu installieren und aktuell zu halten (Shopware-Release-Notes 6.5.8.18). Ein Jahr später folgte trotzdem 6.5.8.19, als ausdrückliche Ausnahme, zu der wir weiter unten kommen.

Für die Praxis heißt das: Seit Juni 2025 ist 6.5 auf einen einzigen regulären Versorgungsweg angewiesen. Wie tragfähig er ist, hängt davon ab, was das Plugin abdecken kann.

Was das Security-Plugin abdeckt und was nicht

Das Security-Plugin (SwagPlatformSecurity) überträgt Sicherheitskorrekturen in bestehende Installationen, ohne dass Shopware selbst aktualisiert werden muss. Es ist kostenlos, wird von Shopware gepflegt, und die Version 2.x für Shopware 6.5 ist in der Kompatibilitätstabelle als gepflegt markiert (Shopware-Doku Security Plugin). Shopware beschreibt das Plugin ausdrücklich als Überbrückung bis zu einem regulären Update, nicht als Ersatz dafür (Shopware-Doku Security Plugin).

Die wichtigste Grenze steht gleich im ersten Abschnitt der Dokumentation: Sicherheitsprobleme in Abhängigkeiten wie Symfony oder Twig deckt das Plugin nicht ab, sie verlangen ein Update der Abhängigkeit oder von Shopware (Shopware-Doku Security Plugin). Hält die composer.lock eine veraltete Bibliothek fest, bleibt die Installation trotz aktivem Plugin angreifbar. Shopware 6.5.8.19 bindet Symfony an die Reihe 6.4 und Twig an Version 3.26.0 oder neuer innerhalb von 3.x (GitHub shopware/shopware). Symfony 6.4 erhält noch bis November 2027 Sicherheitskorrekturen (symfony.com). Solche Korrekturen erreichen einen 6.5-Shop aber nur über ein Composer-Update im Projekt, und nur, solange die neue Bibliotheksversion zu den Vorgaben von 6.5 passt.

Die zweite Grenze betrifft das Plugin selbst. In manchen Fällen lässt sich eine Lücke nicht für jede betroffene Version sicher oder vollständig über das Plugin schließen; dann nennt das jeweilige Advisory ein Update als Weg (Shopware-Doku Security Plugin). Für eine Reihe ohne Patch-Releases ist das der heikle Fall, denn ein Update innerhalb von 6.5 gibt es nicht mehr.

August und September 2026: Kernpatches nur für 6.6 und 6.7

Wie sich der Unterschied auswirkt, zeigen die beiden Sicherheitsrunden des Spätsommers. Am 25.08.2026 erschienen 6.6.10.23 und 6.7.13.1; die Release Notes zu 6.6.10.23 nennen neun behobene Schwachstellen, darunter einen Ausbruch aus der Sandbox für App Scripts (Shopware-Release-Notes 6.6.10.23). Am 16.09.2026 folgten 6.6.10.25 und 6.7.14.1, beide als Sicherheitsrelease gekennzeichnet (Shopware-Release-Notes 6.6.10.25). Eine 6.5-Version gab es zu keinem der beiden Termine; der letzte Stand der Reihe bleibt 6.5.8.19 vom 02.06.2026 (endoflife.date).

Alle drei Advisories stufen die Lücke als kritisch ein. Die App-Script-Lücke erlaubte einer bösartigen oder kompromittierten App, beliebige PHP-Funktionen und Betriebssystembefehle mit den Rechten des Webserver-Prozesses auszuführen; betroffen sind 6.5 ab 6.5.4.0 sowie 6.6 und 6.7 bis zu den korrigierten Versionen (GitHub-Advisory GHSA-6qhw-38wm-7g7h). Über die zweite Lücke konnte ein nicht angemeldeter Angreifer den Link zum Zurücksetzen des Passworts eines Administrators auf eine fremde Domain umlenken (GitHub-Advisory GHSA-xj2c-8fw5-mr6m). Die Webhook-Lücke nennt 6.5.x und ältere Versionen ausdrücklich als betroffen (GitHub-Advisory GHSA-r432-q883-wgvf).

Für 6.5 hat Shopware in beiden Runden am selben Tag nachgezogen: Version 2.0.22 des Security-Plugins vom 25.08.2026 enthält unter anderem die Fixes für die App-Script- und die Passwort-Lücke, Version 2.0.23 vom 16.09.2026 den Fix für die Webhook-Lücke (Shopware Store, Changelog Security Plugin). Das gehört fair in die Bewertung: Wer das Plugin aktuell hielt, war in diesen Runden kaum schlechter gestellt als mit einem Patch-Release. Die Einschränkung liegt im Zeitraum und in den Grenzen des Plugins, und beides zusammen ergibt die Frist.

Die Twig-Lücke vom Juni 2026: wo das Plugin nicht hilft

Was passiert, wenn eine Lücke außerhalb des Shopware-Codes liegt, zeigte 6.5.8.19 vom 02.06.2026. Das Release enthielt einen Sicherheitsfix in Twig, und Shopware schrieb dazu, das Security-Plugin könne die Installation in diesem Fall nicht wie gewohnt schützen; nötig sei ein Twig-Update, das mit dem Patch ausgeliefert werde (Shopware-Release-Notes 6.5.8.19). Shopware nannte das Release eine absolute Ausnahme und veröffentlichte es nach eigenen Worten aus Kulanz, obwohl 6.5 nicht mehr unterstützt werde (Shopware-Release-Notes 6.5.8.19).

Technisch steckt die Ausnahme in einer Zeile der composer.json: 6.5.8.18 verlangte Twig ab Version 3.20, 6.5.8.19 ab Version 3.26.0 (GitHub shopware/shopware). Dass eine neue Twig-Version mehr braucht als eine geänderte Versionsangabe, zeigen die Release Notes der neueren Reihen: 6.7.12.1 vom 06.07.2026 brachte die Kompatibilität mit Twig 3.28 (Shopware-Release-Notes 6.7.12.1), 6.6.10.27 vom 24.09.2026 die Kompatibilität mit Twig 3.29 (Shopware-Release-Notes 6.6.10.27). Für 6.6 und 6.7 kommen solche Anpassungen als reguläre Patches. Für 6.5 gibt es diesen Kanal nicht mehr.

Ob Shopware bei einer künftigen Lücke in Twig oder Symfony erneut eine Ausnahme macht, ist offen. Planen lässt sich damit nicht.

PHP: der zweite Zeitplan, der bei 6.5 weniger drängt

Neben Shopware läuft der Kalender von PHP. Shopware 6.5.8.19 lässt PHP 8.1, 8.2 und 8.3 zu (GitHub shopware/shopware). PHP 8.1 erhält seit dem 31.12.2025 keine Sicherheitskorrekturen mehr, PHP 8.2 nur noch bis zum 31.12.2026, PHP 8.3 bis zum 31.12.2027 (php.net). Ein 6.5-Shop auf PHP 8.1 läuft also schon heute auf einer unversorgten Laufzeit, einer auf PHP 8.2 ab dem Jahreswechsel, knapp zwei Monate vor dem Ende im Kalender von Shopware. Wer bereits PHP 8.3 nutzt, hat von dieser Seite bis Ende 2027 Ruhe.

Das PHP-Argument trägt für 6.5 deshalb nur bedingt. Wichtig wird es beim Upgrade: Shopware 6.6 setzt PHP 8.2 voraus (Shopware-Release-Notes 6.6.0.0), und 6.7.15.0 lässt PHP 8.2 bis 8.5 zu (GitHub shopware/shopware). Shopware empfiehlt, PHP vor einem Major-Update auf die Mindestversion der neuen Shopware-Version anzuheben (Shopware-Doku Updates). PHP 8.3 ist damit die Brücke: Es ist für 6.5, 6.6 und 6.7 zulässig und erhält über das geplante Upgrade-Fenster hinaus Sicherheitskorrekturen. Wie ein PHP-Wechsel im Einzelnen abläuft, beschreibt der Beitrag zum Supportende von PHP 8.2 am Beispiel von WordPress; die Prüfschritte gelten für Shops genauso.

Grundlage der Spalten zu Shopware sind die PHP-Vorgaben in der composer.json der jeweiligen Version (GitHub shopware/shopware). Als getestet führen die Release Notes von 6.6.10.28 PHP 8.2 und 8.4 (Shopware-Release-Notes 6.6.10.28), die von 6.7.15.0 PHP 8.2, 8.4 und 8.5 (Shopware-Release-Notes 6.7.15.0). PHP 8.3 ist zulässig, steht dort aber nicht. Wer 8.3 als Brücke nutzt, testet den Shop deshalb auf Staging mit genau dieser Version, bevor er live umstellt.

Warum das Ziel 6.7 heißt und nicht 6.6

Shopware empfiehlt, von jeder Hauptversion auf die jeweils nächste zu aktualisieren (Shopware-Doku Updates). Für einen 6.5-Shop führt der Weg also über 6.6. Dort stehen zu bleiben, lohnt sich aber kaum: Der Extended Support für 6.6 läuft laut Shopware, bis 6.8 verfügbar ist, und 6.8 ist für 2027 geplant (Shopware-Ankündigung, November 2025). Ein Shop, der im Februar 2027 auf 6.6 ankommt, stünde womöglich schon im selben Jahr vor dem nächsten Sprung.

6.7 ist die laufende Reihe. Für selbst gehostete Installationen erscheinen Minor-Versionen monatlich (Shopware Release Policy), und mit ihnen kommen Hinweise auf 6.8, die sich schrittweise abarbeiten lassen. Die Brüche auf dem Weg sind bekannt: 6.6 hob Symfony auf Version 7 und PHP 8.2 zur Mindestversion (Shopware-Release-Notes 6.6.0.0), 6.7 stellte den Build der Administration von Webpack auf Vite um und entfernte die Kompatibilitätsschicht für Vue 2 (Shopware-Release-Notes 6.7.0.0). Was das für eigene Erweiterungen bedeutet, beschreibt der Beitrag zur Plugin-Migration auf Shopware 6.7.

1. PHP 8.3 auf 6.5: die Laufzeit vorab wechseln, solange der Shop noch auf 6.5 läuft.
2. 6.5.8.19 und aktuelles Security-Plugin: den Ausgangsstand vereinheitlichen, damit das Upgrade auf einer bekannten Basis startet.
3. Zwischenstufe 6.6: auf der Staging-Umgebung bis zur letzten 6.6-Version aktualisieren, Migrationen ausführen und Erweiterungen in ihrer 6.6-Fassung prüfen.
4. Zielstufe 6.7: auf die aktuelle Minor-Version heben und Erweiterungen sowie Theme in der 6.7-Fassung testen.
5. Livegang: den geprobten Ablauf im abgestimmten Wartungsfenster wiederholen und danach PHP 8.4 als nächsten Schritt einplanen.

Fahrplan bis Ende Februar 2027

Zwischen Mitte Oktober und Ende Februar liegen gut vier Monate, mit Black Week und Weihnachtsgeschäft in der Mitte. In dieser Zeit ändert kaum ein Händler gern etwas am Live-Shop. Der Plan legt die Arbeit deshalb so, dass sich am Live-System bis zum Jahreswechsel möglichst wenig ändert und der Umstieg im Januar erfolgt.

1. Oktober: Bestandsaufnahme. Welche 6.5-Version und welche PHP-Version laufen, welche Erweiterungen aus dem Store und welche eigenen sind installiert, welche Schnittstellen hängen am Shop? Parallel eine Staging-Umgebung aufsetzen, mit anonymisierten Daten, wie im Beitrag Shopware-Staging ohne echte Kundendaten beschrieben.
2. November: PHP 8.3 auf Staging und danach live einführen, falls noch nicht geschehen. Für jede Erweiterung klären, ob es Fassungen für 6.6 und 6.7 gibt; eigene Plugins und das Theme portieren.
3. Dezember: das Upgrade von 6.5 über 6.6 auf 6.7 auf der Staging-Umgebung mehrfach proben, jeweils von einem frischen Abzug. Im Live-Shop nur Updates des Security-Plugins.
4. Januar: Abnahme auf Staging mit den wichtigsten Abläufen: Suche, Warenkorb, Checkout, Zahlungsarten, Schnittstellen und E-Mails. Danach der Livegang in einem ruhigen Zeitfenster.
5. Februar: Puffer für Nacharbeiten. Wer im Januar nicht fertig wird, hat hier die letzte Gelegenheit vor dem Ende im Kalender.

Nach dem Livegang beginnt der normale Wartungsrhythmus: Minor-Versionen der Reihe 6.7 in regelmäßigen Abständen, Sicherheitsreleases zeitnah. Wie sich Updates mit geringem Risiko einspielen lassen, zeigt der Beitrag Shopware-Updates sicher einspielen. Und weil 2027 nicht nur bei Shopware Fristen bringt, lohnt ein Blick in den Fristenkalender 2027 für Onlineshops.

Bis zum Upgrade: was ein 6.5-Shop jetzt braucht

Bis der Umstieg live ist, bleibt das Plugin der einzige reguläre Weg für Korrekturen am Shopware-Code. Damit er trägt, braucht es einige Routinen:

• Security-Plugin installiert und auf dem neuesten 2.x-Stand; nach jedem Plugin-Update den Cache leeren, damit neue Fixes geladen werden (Shopware-Doku Security Plugin).
• composer audit regelmäßig ausführen und nur die gemeldeten Pakete gezielt aktualisieren, nicht pauschal alle (Shopware-Doku Security Plugin).
• Die Advisories im GitHub-Repository von Shopware verfolgen und prüfen, ob für 6.5 ein Fix im Plugin vorliegt oder ein Update verlangt wird.
• Die Berechtigung zum Anlegen von Webhooks auf vertrauenswürdige Administratoren und Integrationen beschränken, wie es das Advisory zur Webhook-Lücke als Übergangsmaßnahme nennt (GitHub-Advisory GHSA-r432-q883-wgvf).
• Apps nur aus vertrauenswürdigen Quellen installieren und installierte Apps regelmäßig durchsehen.
• Datenbank und Dateien regelmäßig sichern und die Wiederherstellung mindestens einmal auf Staging ausprobieren.

Die Abhängigkeiten eines Shops sind dabei ein eigenes Risiko, unabhängig von Shopware. Wie sich Composer- und npm-Pakete kontrolliert aktualisieren lassen, beschreibt der Beitrag zu Supply-Chain-Angriffen auf den Shop-Stack. Einen Überblick über die übrigen Schutzebenen gibt IT-Sicherheit im E-Commerce.

So begleitet XICTRON den Umstieg von 6.5

Wir setzen den Umstieg als Projekt mit festem Ablauf um: Bestandsaufnahme, Probe auf Staging, Livegang im abgestimmten Fenster. Der Umfang hängt vor allem von der Zahl eigener Erweiterungen und vom Theme ab, deshalb beginnt jedes Projekt mit einer Inventur.

Wenn Sie wissen möchten, wie groß der Schritt für Ihren Shop ist, sprechen Sie uns an. Für eine erste Einschätzung reichen in der Regel die Shopware-Version, die PHP-Version und die Liste der installierten Erweiterungen.