Shopware 6.5 und PHP 8.2 laufen aus: Was bis Februar 2027 passieren muss

1. Die Termine auf einen Blick

Laut endoflife.date (Stand 8. Oktober 2026) endet die Security-Versorgung für Shopware 6.5 am 28. Februar 2027. Aktiven Support gibt es dort seit dem 28. März 2024 nicht mehr, und reguläre Core-Patches für 6.5 sind laut einer Agentur-Auswertung schon seit Juni 2025 eingestellt; die letzte reguläre Version war 6.5.8.18. Für 6.6 und 6.7 nennt endoflife.date jeweils den 28. Februar 2028.

Bei PHP ist die Lage ähnlich: PHP 8.2 bekommt laut php.net bis zum 31. Dezember 2026 Sicherheitsfixes. PHP 8.1 hat sie bereits seit Ende 2025 nicht mehr. Shopware 6.5 läuft laut endoflife.date auf PHP 8.1 bis 8.3, Shopware 6.6 und 6.7 auf PHP 8.2 bis 8.5.

Ein Hinweis zur Belastbarkeit: Shopware koppelt die Support-Phasen an Major-Releases, nicht an feste Kalenderdaten. Die Daten oben sind der aktuelle Stand des Kalenders, keine schriftliche Zusage. Das spricht eher für früheres als für späteres Handeln.

2. Was „End of Life“ für deinen Shop praktisch bedeutet

Nach dem Stichtag läuft der Shop weiter. Es passiert nichts Sichtbares, und genau das macht es gefährlich. Neu bekannt werdende Lücken in Shopware oder PHP werden für deine Version nicht mehr geschlossen. Dass das keine theoretische Sorge ist, zeigt die Store-API-Lücke vom August: Sansec beschreibt, wie ein Angreifer über die Store API ein Administratorkonto übernehmen und PHP auf dem Server ausführen kann (CVSS 8.6, Fix in 6.7.13.1 und 6.6.10.23). Der dafür nötige Sales-Channel-Schlüssel liegt bei Headless-Storefronts ohnehin im Client.

Auch PCI- und Hosting-Anforderungen sowie Cyber-Versicherungen verlangen in der Regel supportete Software. Wie streng das bei dir ist, steht im Vertrag, nicht in diesem Artikel.

3. Das Security-Plugin ist eine Brücke, kein Zustand

Shopware stellt für ältere Versionen Sicherheitsfixes über das Security-Plugin bereit; so beschreibt es auch die Release Policy. Zwei Einschränkungen solltest du kennen. Erstens deckt das Plugin laut der oben verlinkten Auswertung keine Lücken in Symfony und Twig ab; dafür braucht es Dependency-Updates. Zweitens ist ab dem Stichtag auch diese Versorgung Geschichte. Wer 6.5 betreibt, nutzt das Plugin sinnvoll nur noch als Puffer bis zum Upgrade.

Prüfe deshalb heute, ob das Security-Plugin installiert und aktuell ist. Die Version deines Shops zeigt php bin/console --version.

4. Die richtige Reihenfolge: Inventur, PHP, Shopware

Der häufigste Fehler ist, alles gleichzeitig anzufassen. Besser in drei Schritten:

• Inventur: Alle Plugins, Themes und Eigenentwicklungen auflisten. Pro Eintrag klären: Gibt es eine Version für 6.7? Wer pflegt sie? Ersetzen oder anpassen? Bei Store-Erweiterungen reicht oft ein Blick in die Kompatibilitätsangabe, bei Eigenentwicklungen und alten Agentur-Plugins wird es aufwendig.
• PHP separat anheben: Solange du auf 6.5 bist, ist PHP 8.3 die höchste unterstützte Version. Die Umstellung kannst du daher vor dem Shopware-Upgrade testen und produktiv nehmen und so den PHP-8.2-Stichtag entschärfen. Das ist ein eigenes, überschaubares Release.
• Shopware schrittweise heben: Plane den Weg über 6.6 nach 6.7 ein und halte dich an den jeweiligen Upgrade-Guide, den es in der Entwicklerdokumentation pro Major-Version gibt. Mit einem Staging-System, das Produktivdaten spiegelt, sind das meist Tage, nicht Wochen, sofern die Plugin-Lage geklärt ist.

5. Wo es erfahrungsgemäß hakt

Die Stolpersteine sind selten der Core, sondern das Drumherum: Themes, die tief in Twig-Blöcke eingreifen, Plugins ohne Updatepfad, abgekündigte Zahlungs- und Versandanbieter-Module und Schnittstellen zu ERP oder PIM, die auf alte Datenstrukturen bauen. Plane Zeit für Regressionstests an Checkout, Preislogik und Rechnungsdokumenten ein. Gerade bei B2B-Shops mit Staffelpreisen und Kundengruppen fallen Fehler sonst erst bei der ersten Großbestellung auf.

Dazu die Frage, ob du direkt auf 6.7 gehst oder auf 6.6 stoppst. Für 6.6 nennt endoflife.date dasselbe Datum wie für 6.7, den 28. Februar 2028. Allerdings gilt 6.6 laut Release Policy als Extended Support und ist eine Zwischenstation. Ich würde nach 6.7 ziehen, weil du dann nur einmal migrierst.

6. Shopware 6.8 im Blick behalten

Shopware 6.8 ist laut einer Agentur-Auswertung für 2027 geplant, ein genaues Datum gibt es nicht. Nach demselben Upgrade-Guide-Entwurf (Stand September, kann sich ändern) ist die Konfiguration per XML seit 6.7.14.0 veraltet. Betroffen sind services*.xml und routes*.xml in Plugins sowie XML-Dateien im Projektverzeichnis config/. Wer jetzt migriert und eigene Plugins pflegt, spart sich später einen zweiten Anlauf. Lies dazu den Überblick zur 6.8-Vorbereitung, behandle ihn aber als Zwischenstand.

7. Zeitplan bis Februar

• November: Version und Security-Plugin prüfen, Plugin-Inventur, Staging aufsetzen.
• Anfang Dezember: PHP 8.3 auf Staging testen, vor Weihnachten produktiv nehmen oder bewusst auf Januar legen, aber vor dem 31.12. planen.
• Januar: Shopware-Upgrade auf Staging, Regressionstests, Plugin-Ersatz.
• Februar: Go-Live mit Rückfallplan, Puffer vor dem 28.

Weihnachtsgeschäft und E-Rechnungspflicht zum 1. Januar konkurrieren um dieselben Zeitfenster. Wer beides trägt, sollte die Reihenfolge früh festlegen.