Shopware 6.7: Alle Releases, Security-Stand und E-Rechnungspflicht im Überblick
Stand: 09.11.2026, Shopware 6.7.16.0 released (02.11.2026)
Shopware 6.7.16.0 ist seit dem 02.11.2026 verfügbar. Für Betreiber am wichtigsten: Integrationen und Nicht-Administratoren erreichen MCP nur noch mit expliziter Freigabe, bestehende Integrationen verlieren den Zugriff, bis er freigegeben wird. Dazu kommen eine CSP-Härtung für HTML- und SVG-Dateien unter public/media und public/thumbnail sowie Rabattanzeigen gegen den Niedrigstpreis der letzten 30 Tage. Als Security Update ist 6.7.16.0 nicht gekennzeichnet, das letzte Security Update ist 6.7.14.1 vom 16.09.2026. Wer B2B-Kunden beliefert, sollte das nächste Update mit der Vorbereitung auf die E-Rechnungspflicht ab 01.01.2027 verbinden.
Release-Zeitplan Shopware 6.7
Termin | Meilenstein | Status |
|---|---|---|
25.08.2026 | 6.7.13.1, als Security Update gekennzeichnet | released |
16.09.2026 | 6.7.14.1, als Security Update gekennzeichnet | released |
23.09.2026 | Security Plugin 4.0.16, keine neuen Security-Fixes | released |
30.09.2026 | 6.7.15.0: Admin-Navigation, Dark Mode (experimentell), Copilot Agentic stabil | released |
07.10.2026 | 6.7.15.1: 12 Bugfixes, optionaler Gewährleistungshinweis im Checkout | released |
02.11.2026 | 6.7.16.0: MCP-Allowlist, CSP für HTML und SVG in media und thumbnail, Rabatt gegen 30-Tage-Niedrigstpreis | released |
01.01.2027 | E-Rechnung: Ausstellungspflicht B2B ab 800.000 Euro Vorjahresumsatz | gesetzlich festgelegt |
2027 | Shopware 6.8 | angekündigt, ohne Termin |
Zum Datum von 6.7.15.0: endoflife.date führt den 30.09.2026, in einigen Ankündigungen taucht der 01.10.2026 auf. Für Ihre Planung spielt der Tag keine Rolle, maßgeblich ist der Tag in Ihrem Composer-Lock.
6.7.16.0: MCP-Allowlist, CSP-Härtung und Rabatte (released)
Shopware 6.7.16.0 ist laut Shopware-Changelog am 02.11.2026 erschienen. Die Release-News für November 2026 und die Release Notes auf GitHub enthalten drei Punkte, die Agenturen und Betreiber vor dem Update kennen sollten.
MCP-Zugriff nur noch mit Allowlist
Die Release-News formulieren es so: „integrations and non-administrator users can only access MCP capabilities that have been explicitly allowed.“ Laut Release Notes gilt: Ist keine Allowlist gesetzt, ist kein MCP-Zugriff mehr erlaubt. Bisher war in diesem Fall alles erlaubt. Nur Administratoren umgehen die Allowlist, Integrationen nie.
Für Betreiber heißt das: Bestehende Integrationen und Nicht-Admin-Benutzer, die MCP nutzen, verlieren den Zugriff, bis er freigegeben wird. Die Freigabe erfolgt unter Einstellungen, System, Integrationen beziehungsweise auf der Detailseite des Benutzers. Prüfen Sie vor dem Update, welche Integrationen MCP-Funktionen aufrufen, und hinterlegen Sie die Freigaben im selben Wartungsfenster. Welche Wege es für einen Chatbot im Shop gibt, von der Store-App über MCP bis zum Eigenbau, beschreibt der Beitrag Chatbot in Shopware 6 integrieren.
CSP für HTML und SVG unter public/media und public/thumbnail
Mit PR #21659 erhält die Apache-Vorlage public/.htaccess.dist eine restriktive Content-Security-Policy für vorhandene .html-Dateien unter public/media und public/thumbnail. Die bestehende Richtlinie für SVG-Dateien wird auf denselben Wert verschärft. Skripte, Objekte, Frames, Base-URIs und Formular-Ziele sind damit gesperrt, Bilder und Styles bleiben erlaubt.
Wichtig: Die Härtung greift nur, wenn die deployte .htaccess den aktualisierten Block enthält. Fehlen die Shopware-Update-Marker in Ihrer .htaccess, müssen Sie den Abschnitt laut Release Notes manuell übernehmen. Wer nginx statt Apache einsetzt, bekommt die Änderung über diese Vorlage nicht.
CVE-2026-104937 (CERT/CC VU#157374)
CERT/CC beschreibt in VU#157374 einen Angriffsweg über die Media-Upload-API: Hochgeladene HTML-Dateien werden ohne wirksame Security-Header als text/html ausgeliefert. Öffnet ein Administrator eine präparierte Media-URL, kann eingebettetes JavaScript dessen Token stehlen. Ein Shopware-Advisory dazu gibt es weiterhin nicht. Die CSP-Änderung in 6.7.16.0 adressiert den beschriebenen Angriffsweg, Shopware hat sie aber nicht als Fix für diese CVE ausgewiesen. Der Workaround aus dem CERT/CC-Eintrag bleibt sinnvoll: die Medienverwaltung auf vertrauenswürdige Rollen beschränken oder HTML-Uploads deaktivieren.
Rabattanzeige gegen den 30-Tage-Niedrigstpreis
Laut Release-News berechnet die Storefront die Ersparnis künftig gegen den Niedrigstpreis der letzten 30 Tage statt gegen den durchgestrichenen Preis. Ist der aktuelle Preis nicht niedriger, wird kein Rabatt mehr angezeigt. Die Release Notes nennen dazu zwei Punkte für Projekte mit eigenen Anpassungen: Das Snippet general.listPricePreviously lautet jetzt „Lowest price (last 30 days): %price%“, und die Rule-Builder-Bedingung „Item with price/list price ratio“ trifft Positionen ohne Listenpreis nicht mehr. Wer dort „Is equal to 0“ nutzt, sollte auf „Is empty“ umstellen. Eigene Templates und Rabattregeln gehören deshalb in den Test vor dem Update.
6.7.15.1: Bugfix-Release mit Checkout-Bezug (released)
6.7.15.1 ist ein reines Wartungsrelease. Die 12 geschlossenen Issues verteilen sich auf fünf Bereiche: Regelauswertung im Rule Builder, Checkout im Zusammenspiel mit GARAN, Limits beim Lagerbestand, Bereinigung von Theme-Assets und Validierung von Sales Channels.
Für Projekte mit eigenen Plugins sind zwei Punkte relevant. Änderungen an der Regelauswertung können Rabatt-, Versand- oder Zahlungsregeln betreffen, die bisher durch einen Fehler zufällig gegriffen haben. Und die Bereinigung der Theme-Assets kann alte, von Plugins abgelegte Dateien entfernen, auf die ein Template noch hart verweist. Beides findet man nur mit einem Test gegen echte Regeln und echte Themes.
Optionaler Gewährleistungshinweis im Checkout
Neu ist ein optionaler Inline-Hinweis zur gesetzlichen Gewährleistung im Checkout. Er ist standardmäßig nicht aktiv. Ob und wie Sie ihn einsetzen, ist eine Frage an die Rechtsberatung des Shopbetreibers. Technisch sollten Sie nach dem Update prüfen, ob ein eigenes Checkout-Template den neuen Block überschreibt oder doppelt ausgibt.
6.7.15.0: Admin-Navigation, Dark Mode und Copilot Agentic (released)
Laut shopware.com bringt 6.7.15.0 eine überarbeitete Navigation in der Administration, einen experimentellen Dark Mode, die Kennzeichnung von „Copilot Agentic“ als stabil sowie Verbesserungen an GARAN.
Admin-Navigation (released): Wer eigene Module per Admin-Extension in die Navigation einhängt, sollte die Position und das Elternelement nach dem Update prüfen. Menüpunkte, die bisher unter einem bestimmten Eintrag standen, können in der neuen Struktur woanders landen.
Dark Mode (experimentell): Eigene Admin-Komponenten mit hart codierten Farben fallen im Dark Mode sofort auf. Für neue Komponenten lohnt es sich, Farben über die vorhandenen Design-Tokens der Administration zu beziehen. Für Bestandskomponenten ist das kein Pflichtumbau, solange der Modus experimentell bleibt.
Copilot Agentic (stabil): Damit wird die Linie fortgesetzt, die mit dem Agentic-Commerce-Ansatz in 6.7.9.0 begonnen hat. Die Funktionen sind jetzt als stabil gekennzeichnet. Wer sie nutzt, sollte trotzdem eigene Freigabeprozesse für automatisch erzeugte Inhalte definieren, bevor sie live gehen.
Security-Stand: Was wirklich gepatcht werden muss
Weder 6.7.15.0, 6.7.15.1 noch 6.7.16.0 sind im Shopware-Changelog als Security Update gekennzeichnet. Auch das Security Plugin 4.0.16 vom 23.09.2026 ist laut Store-Eintrag ausdrücklich kein Security Release. Als Security Update gekennzeichnet sind im Changelog 6.7.13.1 vom 25.08.2026 und zuletzt 6.7.14.1 vom 16.09.2026.
Daraus folgt eine klare Prioritätenliste. Shops unterhalb von 6.7.14.1 haben einen dokumentierten Handlungsbedarf und sollten mindestens diesen Stand erreichen. Shops auf 6.7.14.1 oder höher können 6.7.16.0 im regulären Wartungsfenster einplanen, wegen der MCP-Allowlist aber mit einem Blick auf die eigenen Integrationen. Hintergründe zum Security Release finden Sie im Überblick zum Sicherheitsupdate 6.7.13.1.
Wer selbst Plugins für Kundenshops oder den Shopware Store entwickelt, hat seit dem 11.09.2026 zusätzlich Meldepflichten nach dem Cyber Resilience Act. Was das konkret bedeutet, steht im Beitrag zu den CRA-Pflichten für Plugin-Hersteller.
So prüfen Sie den aktuellen Stand und aktualisieren in einer DDEV-Umgebung:
# Aktuell installierte Core-Version anzeigen
ddev composer show shopware/core | grep versions
# Core und zugehörige Pakete auf 6.7.16.0 heben
ddev composer require shopware/core:6.7.16.0 \
shopware/administration:6.7.16.0 \
shopware/storefront:6.7.16.0 \
shopware/elasticsearch:6.7.16.0 --update-with-all-dependencies
# Migrationen und Update-Routine ausführen
ddev exec bin/console system:update:finish
# Theme neu kompilieren, wichtig wegen der Asset-Bereinigung
ddev exec bin/console theme:compile
ddev exec bin/console cache:clearPakete, die Sie nicht einsetzen, etwa shopware/elasticsearch, lassen Sie aus dem Befehl heraus. Nach theme:compile lohnt ein Blick in die Browser-Konsole auf 404-Fehler für Assets. Genau dort zeigen sich Templates, die auf entfernte Dateien verweisen. Auf Apache-Servern prüfen Sie nach dem Update zusätzlich, ob die deployte public/.htaccess den neuen CSP-Block aus .htaccess.dist enthält.
E-Rechnungspflicht: Was Shopware-Projekte bis Januar 2027 klären sollten
Die E-Rechnungspflicht landet bei vielen Shops im selben Wartungszyklus wie das nächste Shopware-Update. Der gesetzliche Rahmen in Deutschland: Seit dem 01.01.2025 müssen Unternehmen E-Rechnungen im B2B-Bereich empfangen können. Ab dem 01.01.2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz B2B-Rechnungen elektronisch ausstellen. Ab dem 01.01.2028 gilt die Ausstellungspflicht für alle inländischen B2B-Umsätze. Rechnungen an Endverbraucher sind nicht erfasst.
ZUGFeRD und XRechnung: welches Format wofür
ZUGFeRD (international Factur-X) ist ein Hybridformat: ein lesbares PDF mit eingebetteter XML-Datei. Für die meisten B2B-Kunden ist das der pragmatische Weg, weil der Empfänger das Dokument auch ohne Spezialsoftware öffnen kann. XRechnung ist reines XML ohne PDF-Ebene und wird vor allem von öffentlichen Auftraggebern verlangt. Beliefert Ihr Shop Behörden, kommt zusätzlich die Leitweg-ID als Pflichtangabe dazu.
Drei Wege zur E-Rechnung in Shopware
Core-Funktion (released): Laut Anbieterübersichten bringt Shopware ab 6.6.10 beziehungsweise in der 6.7-Linie native Unterstützung mit. Rechnungen, Stornorechnungen und Gutschriften lassen sich als ZUGFeRD-Hybrid oder als separate XML nach EN 16931 ausgeben. Felder wie Buyer Reference und Leitweg-ID sind vorgesehen. Wer auf 6.7.16.0 aktualisiert, hat diese Basis also bereits im System.
Erweiterungen aus dem Store: Für reine XRechnung-Strukturen, eine Peppol-Anbindung oder automatisierten Versand per E-Mail gibt es spezialisierte Erweiterungen, etwa von IWV oder Codebarista. Sinnvoll wird das, wenn der Core-Umfang für Ihre Prozesse nicht reicht, zum Beispiel bei Peppol-Pflicht einzelner Großkunden.
ERP als führendes System: Entsteht die Rechnung in einer Warenwirtschaft oder einem ERP, erzeugt meist dieses System die E-Rechnung. Shopware ist dann Datenlieferant. Prüfen müssen Sie hier vor allem die Schnittstelle, nicht den Shop. Worauf es bei dieser Schnittstelle ankommt, damit keine Bestellung oder Rechnung unterwegs verloren geht, beschreibt der Beitrag zur ERP-Anbindung mit Symfony.
Welche Dokumenttypen in Ihrer Installation registriert sind, sehen Sie direkt in der Datenbank:
-- Registrierte Dokumenttypen auflisten
-- Nach dem Update sollten Einträge für strukturierte E-Rechnungen auftauchen
SELECT technical_name, LOWER(HEX(id)) AS id
FROM document_type
ORDER BY technical_name;Fehlen dort Einträge für strukturierte Formate, läuft die Installation noch auf einem älteren Stand oder die Rechnung kommt aus einem anderen System. Bevor Sie eine Erweiterung kaufen, lohnt sich deshalb zuerst der Blick auf die eigene Version.
Der unterschätzte Teil: Stammdaten
Eine E-Rechnung ist nur so gut wie die Daten dahinter. Fehlt bei B2B-Kunden die Umsatzsteuer-ID, steht die Firmenadresse im Freitextfeld oder fehlt bei Behördenkunden die Leitweg-ID, erzeugt auch der Core eine unvollständige Rechnung. Ein Validator gegen EN 16931 zeigt solche Lücken schnell. Die Bereinigung der Kundendaten gehört deshalb in denselben Plan wie das Update. Die rechtliche Bewertung im Einzelfall bleibt Sache der Steuerberatung.
Shopware 6.8 und 7: Was angekündigt ist (angekündigt / nicht angekündigt)
Shopware 6.8 ist für 2027 angekündigt, einen festen Termin gibt es noch nicht. Shopware 7 ist nicht angekündigt, entsprechende Berichte stammen aus Sekundärquellen und lassen sich nicht bestätigen. Für die Planung bedeutet das: 6.7 bleibt die Linie, auf der Sie in den nächsten Monaten Wartung und E-Rechnung umsetzen. Erweiterungen, die Sie jetzt schreiben, sollten Sie gegen die Deprecations von 6.7 prüfen, damit der Schritt auf 6.8 kein Rewrite wird.
Für die Basis darunter gilt der aktuelle Stand: Symfony 7.4 ist LTS, Symfony 8.1 ist aktuell und 8.2 ist planmäßig für November 2026 vorgesehen. PHP 8.5 ist aktuell, PHP 8.6 planmäßig für den 19.11.2026. Welche PHP-Änderungen für Plugin-Code relevant werden, steht im Sammelartikel zu PHP 8.6.
Was sich seit dem letzten Update geändert hat
- Update 09.11.2026: 6.7.16.0 vom 02.11.2026 ist released und ergänzt.
- Neu: MCP-Allowlist. Integrationen und Nicht-Administratoren erreichen MCP nur noch mit expliziter Freigabe, bestehende Integrationen verlieren den Zugriff bis zur Freigabe.
- Neu: CSP-Härtung in
.htaccess.distfür HTML unter public/media und public/thumbnail sowie für SVG (PR #21659), mit Einordnung zu CVE-2026-104937. Ein Shopware-Advisory gibt es weiterhin nicht. - Neu: Rabattanzeige gegen den 30-Tage-Niedrigstpreis und geänderte Rule-Builder-Bedingung zum Listenpreis.
- Korrigiert: Laut Shopware-Changelog ist 6.7.14.1 vom 16.09.2026 das letzte als Security Update gekennzeichnete Release, nicht 6.7.13.1.
Einordnung für bestehende Projekte
Für Shops unterhalb von 6.7.14.1 ist die Reihenfolge eindeutig: erst den Security-Stand erreichen, dann alles andere. Für Shops auf 6.7.14.1 oder höher ist 6.7.16.0 ein Wartungsupdate mit zwei Prüfpunkten: die MCP-Freigaben für bestehende Integrationen und der CSP-Block in der deployten .htaccess. Dazu kommen die Admin-Navigation und die Asset-Bereinigung aus 6.7.15.x, an denen eigene Erweiterungen auffallen können. Planen Sie dafür einen Testdurchlauf auf Staging ein, bevor Sie live gehen.
Der größere Posten für das vierte Quartal ist bei B2B-Shops die E-Rechnung. Dort entscheidet weniger die Shopware-Version als die Frage, wo die Rechnung entsteht und wie sauber die Kundendaten sind. Wer beides jetzt klärt, kann das nächste Shopware-Update und die Umstellung in einem Durchgang testen.
Bei Shops mit vielen gewachsenen Plugins ohne Tests ist das Update selbst selten das Problem. Schwierig wird es, wenn niemand mehr genau weiß, welches Plugin welche Regel oder welches Template verändert. Wie Sie solche Altlasten bewerten, bevor ein größeres Upgrade ansteht, beschreibt der Artikel Technische Schulden quantifizieren und verständlich machen. Muss ein Projekt dafür an einen neuen Dienstleister übergeben werden, hilft der Risiko-Check vor der Projektübernahme.
Ich aktualisiere diesen Artikel mit jedem relevanten 6.7-Release und sobald es einen Termin für 6.8 gibt.
Solche Themen regelmäßig?
Ich schreibe hier wöchentlich über PHP, Symfony und was sich im Ökosystem tut. Auf LinkedIn teile ich die kürzere Version.
Auf LinkedIn folgen →