Neues Produkthaftungsrecht ab 9. Dezember 2026: Wenn Shopware-Plugins zum Produkt werden
Am 9. Dezember 2026 beginnt in Deutschland das neue Produkthaftungsrecht. Software, Updates und Plugins gelten dann ausdrücklich als Produkt, und die Haftung hängt nicht mehr von einem Verschulden ab. Was der Bundestagsbeschluss vom 8. Oktober für Plugin-Entwickler, Agenturen und Shop-Betreiber bedeutet und welche Nachweise du bis zum Stichtag sauber haben solltest.
1. Was sich am 9. Dezember 2026 ändert
Der Bundestag hat am 8. Oktober 2026 das Gesetz zur Modernisierung des Produkthaftungsrechts beschlossen. Es setzt die EU-Produkthaftungsrichtlinie 2024/2853 um und soll am 9. Dezember 2026 in Kraft treten. Für Produkte, die bis einschließlich 8. Dezember 2026 in Verkehr gebracht wurden, gilt weiter das alte Produkthaftungsgesetz von 1989. Alles, was danach ausgeliefert wird, fällt unter die neuen Regeln. Der Kern: Software gilt ausdrücklich als Produkt. Ob die Lücke vom Hersteller verschuldet war, spielt keine Rolle, denn die Haftung ist verschuldensunabhängig. Der Geschädigte muss Fehler, Schaden und Kausalität darlegen, nicht aber ein Verschulden. Dazu kommt: Der bisherige Selbstbehalt bei Sachschäden fällt weg, und auch der Verlust oder die Zerstörung von Daten zählt künftig als ersatzfähiger Schaden, sofern sie nicht beruflich genutzt wurden. Ob die Bundesrats-Schlussabstimmung bereits durch ist, konnte ich nicht abschließend verifizieren; das Gesetz ist nach den vorliegenden Quellen nicht zustimmungspflichtig.
2. Warum das auch Shopware-Plugins betrifft
Bisher war Software im Produkthaftungsrecht ein Graubereich. Künftig zählen Programme, Apps und eingebettete Software ausdrücklich dazu, ebenso Updates und Sicherheitspatches. Ein Shopware-Plugin, das ausgeliefert wird, ist also ein Produkt im Sinne des Gesetzes. Das gilt für Store-Plugins genauso wie für Individualentwicklungen, die du für einen Kunden baust. Wichtig ist die Einordnung: Die Produkthaftung greift bei Schäden an Leben, Gesundheit und Privatsachen. In der Praxis bei Shop-Software ist der realistische Fall deshalb eher der Datenschaden bei Verbrauchern, etwa wenn eine Sicherheitslücke in einem Plugin Kundendaten preisgibt und dadurch ein ersatzfähiger Schaden entsteht. Reine Vermögensschäden eines Shop-Betreibers, etwa Umsatzausfall nach einem Plugin-Fehler, regelt weiter dein Vertrag und das allgemeine Haftungsrecht. Die Produkthaftung ersetzt beides nicht, sie kommt dazu.
3. Wer haftet in der Kette: Entwickler, Agentur, Shop-Betreiber
Die Richtlinie weitet den Kreis der Haftenden aus. Neben dem Hersteller können Importeure, Bevollmächtigte, Fulfillment-Dienstleister und unter Umständen Online-Plattformen in Anspruch genommen werden. Wer ein Produkt wesentlich verändert, gilt selbst als Hersteller. Für unsere Welt heißt das: Der Plugin-Entwickler ist Hersteller seines Plugins. Eine Agentur, die ein fremdes Plugin stark anpasst oder forkt, kann dadurch in die Herstellerrolle rutschen. Und wer als Händler oder Betreiber kein verantwortliches Glied in der Kette nennen kann, riskiert, selbst zu haften. Entscheidend ist deshalb, dass du auf Nachfrage sagen kannst, wer was gebaut hat und wer für welchen Teil verantwortlich ist. Das gehört in den Vertrag und in die Projektdokumentation, nicht in dein Gedächtnis.
4. Beweislast, Offenlegung und warum Doku jetzt zählt
Eine pauschale Umkehr der Beweislast gibt es nicht. Neu ist aber die Pflicht zur Offenlegung: Gerichte können anordnen, dass ein Beklagter relevante Beweismittel herausgibt, und bei Verweigerung wird der Fehler vermutet. Geschäftsgeheimnisse sollen dabei in einem besonders geschützten Verfahren bleiben; darauf hat laut IHK Frankfurt die IHK-Organisation gedrängt. Praktisch bedeutet das: Wer im Streitfall nachweisen kann, wie er entwickelt, getestet und gepatcht hat, steht besser da. Wer nur "lief bisher immer" sagen kann, steht schlecht da. Changelogs, Pull-Request-Historie, Testprotokolle, dokumentierte Freigaben und Release-Notes sind plötzlich Beweismittel zu deinen Gunsten.
5. Updates, Sicherheitslücken und Support-Ende
Besonders unbequem für Entwickler: Ein fehlendes, erforderliches Sicherheitsupdate oder unzureichende Cybersicherheit kann ein Produkt fehlerhaft machen, solange der Hersteller die Kontrolle behält. Das ist die rechtliche Entsprechung zu dem, was wir technisch ohnehin predigen. Ein Beispiel aus der Shopware-Welt ist die Store-API-Lücke, die Sansec im August dokumentiert hat und die einen Admin-Takeover erlaubte, gefixt in 6.7.13.1 und 6.6.10.23. Wer ein Plugin pflegt, das auf einer Version ohne Security-Support läuft, oder Patches wochenlang liegen lässt, baut sich ein Haftungsrisiko. Das passt zu den Terminen rund um Shopware 6.5 und PHP 8.2: Support-Ende ist nicht nur ein Technikthema, sondern ein Haftungsthema. Ausgenommen bleibt Open Source, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird. Ein kommerziell vertriebenes Plugin fällt nicht darunter, auch wenn der Code offen liegt.
6. Was du bis zum Stichtag tun solltest
Fünf Dinge, die ich bei Kunden und in eigenen Projekten bis Dezember sauber haben will. Erstens: ein Inventar aller Plugins und Eigenentwicklungen mit Version, Verantwortlichem und Support-Status. Zweitens: ein dokumentierter Update- und Patch-Prozess, inklusive Fristen für Sicherheitsupdates. Drittens: Entwicklungs- und Testnachweise, also CI-Läufe, Review-Historie und Release-Freigaben, aufbewahrt statt überschrieben. Viertens: Verträge prüfen. Wer haftet im Innenverhältnis, wie sind Wartung, Support-Laufzeit und Haftungsbegrenzung geregelt, und was gilt, wenn der Kunde selbst Änderungen am Plugin vornimmt? Fünftens: Berufshaftpflicht und Cyber-Versicherung daraufhin ansehen, ob Software-Produkthaftung und Datenschäden abgedeckt sind. Die Produkthaftung lässt sich gegenüber Verbrauchern nicht vertraglich ausschließen; im Innenverhältnis unter Unternehmen lässt sich dagegen vieles sauber regeln, wenn man es vorher tut. Das ist keine Rechtsberatung, die Details gehören mit Kanzlei oder Versicherer geklärt.
7. Sonderfall Headless und Individualprojekte
Bei Headless-Setups mit Next.js ist die Hersteller-Frage noch weniger offensichtlich. Das Frontend, die Anbindung an die Store API, Middleware, ERP-Schnittstellen und eigene Plugins stammen oft von verschiedenen Beteiligten. Kommt es zu einem Fehler, etwa durch falsch gesetzte Caching-Header, die personenbezogene Daten an den falschen Nutzer ausliefern, muss sich nachvollziehen lassen, welche Komponente das verursacht hat. Genau dafür brauchst du saubere Schnittstellenbeschreibungen, Versionsstände pro Komponente und einen klaren Projektvertrag mit Abnahmeprotokoll. Bei Individualentwicklungen für einen einzelnen Kunden gilt zusätzlich: Mit der Abnahme und dem Go-live beginnt faktisch die Phase, in der Updates, Sicherheitspatches und Support-Ende zur Pflicht werden. Wer nach dem Projekt nicht mehr wartet, sollte das schriftlich festhalten und den Kunden ausdrücklich auf die Verantwortung für Updates hinweisen. Ein Wartungsvertrag mit klaren Reaktionszeiten ist hier nicht nur Umsatz, sondern auch Absicherung für beide Seiten.
8. Fazit
Das neue Produkthaftungsrecht ändert keine Code-Zeile, aber die Spielregeln drumherum. Software ist ein Produkt, Updates sind Teil davon, und im Streitfall entscheidet deine Dokumentation. Für Plugin-Entwickler, Agenturen und Freelancer heißt das: Verantwortlichkeiten klären, Patches nachweisbar einspielen, Verträge aktualisieren. Wer das bis zum 9. Dezember erledigt, ist vorbereitet, ohne Panik zu schieben. Und wer es nicht tut, merkt es frühestens im Schadensfall, dann aber teuer.
Plugins im Einsatz und unklare Verantwortlichkeiten? Lass uns das vor dem 9. Dezember klären.
Inventar, Update-Prozess, Dokumentation und Wartungsverträge: Ich gehe mit dir in 30 Minuten durch, wo dein Shop oder dein Plugin-Bestand vor dem Stichtag Lücken hat.
Schriftlich oder im Gespräch — 15 Minuten, unverbindlich.
Newsletter
Mehr davon? Jeden Montag ein Shopware-Thema
Jeden Montag: mein neuer Blog-Artikel plus ein, zwei kurze News aus der Shopware-Welt.
Zum Start als Dankeschön: der Shopware-Update-Check – 30 Prüfpunkte, mit denen du dein nächstes Shopware-Update sauber planst.