Ab Dezember 2026 ist dein Shopware-Plugin ein Produkt: die neue EU-Produkthaftungsrichtlinie

• von Tobias Schäfer • 14 min read
#Shopware #Plugin Development #Recht #E-Commerce

Am 9. Dezember 2026 wird Software zum Produkt im Sinne des EU-Produkthaftungsrechts. Das gilt für das Plugin, das du im Shopware Store verkaufst, und für das Individualmodul, das deine Agentur für einen einzelnen Kunden geschrieben hat. Die Richtlinie (EU) 2024/2853 ersetzt die Richtlinie von 1985, die für Toaster und Leitern geschrieben war und nie klar gesagt hat, ob Software dazugehört.

Die meisten Artikel, die ich seit dem Sommer dazu gelesen habe, hören an dieser Stelle auf, und der Ton liegt irgendwo zwischen “neues Risiko für jeden Entwickler” und “jetzt Versicherung abschließen”. Ich habe die Richtlinie selbst gelesen und das deutsche Gesetz, das sie umsetzt, und halte das direkte Risiko für ein typisches Shopware-Plugin für kleiner. Wer dich danach verklagen kann, ist selten dein Kunde. Was deine Arbeit tatsächlich verändern wird, sind die Regeln zu Updates und der Cyber Resilience Act, der über eine Vermutung an die Produkthaftung andockt.

Dieser Beitrag richtet sich an Store-Hersteller, Agenturen und Freelancer, die Shopware-Code schreiben. Stand: 9. Oktober 2026.

Ich bin Entwickler, kein Anwalt, und dieser Beitrag ist keine Rechtsberatung. Er gibt meine Lesart der Richtlinie, des deutschen Umsetzungsgesetzes und einer Handvoll Veröffentlichungen von Kanzleien wieder. Nationale Gerichte haben nach den neuen Regeln noch keinen einzigen Fall entschieden, mehrere Punkte unten sind also Auslegung. Lass deine Verträge und deine Versicherung von jemandem prüfen, der dafür qualifiziert ist und haftet.

Was sich am 9. Dezember ändert

Die Richtlinie gilt für “Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden” (Art. 2 Abs. 1). Alles, was vorher in Verkehr gebracht wurde, bleibt beim alten Recht (Art. 21). Das deutsche Gesetz sagt es ausdrücklich: Das alte ProdHaftG gilt weiter für Produkte, die bis einschließlich 8. Dezember in Verkehr gebracht wurden.

Software ist ein Produkt. Erwägungsgrund 13 sagt, das gelte “unabhängig von der Art ihrer Bereitstellung oder Nutzung”, also für Software auf einem Gerät, für Software, die über ein Netz abgerufen wird, und für Software, die “durch ein Software-as-a-Service-Modell bereitgestellt wird”. Ein Shopware-Plugin ist drin, ebenso eine Shopware-App, deren Logik auf deinem eigenen Server läuft.

Die Haftung ist verschuldensunabhängig. Die geschädigte Person muss den Fehler, den Schaden und den Kausalzusammenhang beweisen, aber kein Verschulden. Vier Dinge machen ihr das leichter als bisher:

  • Gerichte können den Hersteller zur Offenlegung von Beweismitteln verpflichten, sobald der Kläger seinen Anspruch plausibel gemacht hat (Art. 9). Legst du nicht offen, wird der Fehler vermutet (Art. 10 Abs. 2 lit. a).
  • Die Fehlerhaftigkeit wird vermutet, wenn das Produkt verbindliche Sicherheitsanforderungen nach EU- oder nationalem Recht nicht einhält, die vor genau der Art von Schaden schützen sollen, die eingetreten ist (Art. 10 Abs. 2 lit. b). Hier kommt der Cyber Resilience Act ins Spiel.
  • Wenn der Beweis wegen technischer Komplexität “übermäßig schwierig” ist, vermutet das Gericht Fehler und Kausalität, sobald der Kläger zeigt, dass beides wahrscheinlich ist (Art. 10 Abs. 4). Software ist dafür das Lehrbuchbeispiel.
  • Die alte Selbstbeteiligung von 500 € bei Sachschäden und die optionale Haftungshöchstgrenze (in Deutschland 85 Millionen €) fallen weg. Erwägungsgrund 56 schließt “finanzielle[ ] Obergrenzen” ausdrücklich aus.

Und vertraglich kommst du da nicht raus. Art. 15: Die Haftung gegenüber der geschädigten Person darf nicht “durch eine vertragliche Bestimmung oder durch nationales Recht beschränkt oder ausgeschlossen” werden. Was deine AGB zur Haftung sagen, berührt das nicht.

Wer einen Plugin-Hersteller tatsächlich verklagen kann

Diesen Teil lassen die meisten Zusammenfassungen weg, und für B2B-Software ist er der wichtigste.

Anspruchsberechtigt sind nur natürliche Personen (Art. 5). Und nur für drei Arten von Schäden (Art. 6):

  1. Tod oder Körperverletzung, einschließlich medizinisch anerkannter Beeinträchtigungen der psychischen Gesundheit,
  2. Schäden an Sachen, außer am fehlerhaften Produkt selbst und an Sachen, die “ausschließlich für berufliche Zwecke verwendet werden”,
  3. Vernichtung oder Beschädigung von Daten, “die nicht für berufliche Zwecke verwendet werden”.

Ein Händler, dessen Checkout-Plugin drei Tage lang Kunden doppelt belastet hat, hat nach der Richtlinie keinen Anspruch. Der Shop wird von einem Unternehmen betrieben, die Shopdaten werden beruflich genutzt, und Umsatzausfall ist ein reiner Vermögensschaden, den Erwägungsgrund 24 zusammen mit “Verletzungen der Privatsphäre” ausnimmt. Dieser Fall bleibt, wo er immer war: in deinem Vertrag mit dem Händler, bei Store-Plugins in den Bedingungen von Shopware, und im Deliktsrecht.

Ein Datenleck ist auch nicht erfasst. Erwägungsgrund 20 unterscheidet die “Vernichtung oder Beschädigung von Daten” von “Datenlecks oder Verstößen gegen Datenschutzbestimmungen” und überlässt Letztere der DSGVO. Eine Sicherheitslücke in deinem Plugin, über die jemand Kartendaten abgreift oder die Kundentabelle abzieht, ist also ein DSGVO- und Vertragsproblem, aber keins der Produkthaftung. (Dass es über deinen Code passiert ist, ändert nichts an der Art des Schadens.)

Bleiben die Kunden des Shops, die Verbraucher. Sie können Ansprüche haben, wenn dein Plugin ihre privaten Daten vernichtet oder beschädigt und sie diese nicht kostenlos wiederherstellen können (laut Erwägungsgrund 20 heißt ein Backup: kein Schaden). Denk an ein Personalisierungs-Plugin, das die Fotos speichert, die ein Kunde für eine bedruckte Tasse hochlädt, oder an ein Plugin, das gespeicherte Konfigurationen eines Kunden verwaltet, und das diese dann löscht oder zerschießt. Personenschäden sind im E-Commerce noch seltener. Das Szenario, zu dem ich immer wieder zurückkomme, ist ein Plugin, das Allergen- oder Dosierungsangaben anzeigt und wegen eines Bugs falsche Werte ausgibt. Ob ein Gericht das als fehlerhafte Software behandelt oder als fehlerhafte Information (die laut Erwägungsgrund 13 “nicht als Produkt zu betrachten” ist), weiß ich nicht, und ich habe keinen Kommentator gefunden, der das beantwortet.

Für die meisten Store-Plugins ist das realistische direkte Risiko aus der Richtlinie also klein. Für Plugins, die Uploads von Verbrauchern verarbeiten, gesundheitsrelevante Produktdaten anzeigen oder irgendetwas im B2C-Kundenkonto tun, ist es real.

Updates: keine Pflicht, aber auch keine Ausrede

Die Richtlinie zwingt dich nicht, Updates zu liefern. Erwägungsgrund 51 sagt das in einem Satz: “Diese Richtlinie sieht keine Verpflichtung zur Bereitstellung von Updates oder Upgrades für ein Produkt vor.”

Was sie tut: Sie nimmt dir eine Verteidigung weg. Nach altem Recht konnte ein Hersteller argumentieren, der Fehler habe noch nicht bestanden, als das Produkt das Werk verließ. Nach Art. 11 Abs. 2 verlierst du dieses Argument, wenn der Fehler aus der Software selbst stammt, aus einem Update oder Upgrade oder aus einem “Fehlen von Software-Updates oder -Upgrades, die zur Aufrechterhaltung der Sicherheit erforderlich sind”, solange das Produkt unter deiner Kontrolle steht. Und unter deiner Kontrolle steht es, solange du “in der Lage” bist, “Software-Updates oder -Upgrades selbst bereitzustellen oder durch einen Dritten bereitstellen zu lassen” (Art. 4 Nr. 5 lit. b).

Bei einem Store-Plugin, das du jederzeit aktualisieren kannst, ist das immer der Fall. Praktisch heißt das: Wird eine Sicherheitslücke bekannt und du patchst sie nicht, und führt sie zu einem Schaden, den die Richtlinie erfasst, ist die Verteidigung “beim Release war alles in Ordnung” weg. Lieferst du den Patch und der Händler installiert ihn nicht, entfällt laut Erwägungsgrund 51 die Haftung für diesen Teil.

Daraus folgen zwei Dinge, die ich jetzt angehen würde. Erstens: Halte fest, wann du Sicherheitsfixes veröffentlicht und wie du sie angekündigt hast. Im Streitfall ist das dein Beweis, und nach Art. 9 musst du ihn womöglich ohnehin herausgeben. Zweitens: Leg fest, wann eine Plugin-Version das Ende ihrer Lebensdauer erreicht, und sag das öffentlich. Solange du eine Version verkaufst oder pflegst, kannst du sie aktualisieren, also steht sie unter deiner Kontrolle.

Updates spielen auch für den Stichtag eine Rolle. Ein Plugin, das vor dem 9. Dezember 2026 veröffentlicht wurde, bleibt beim alten Recht, und normale Updates ändern daran nichts. Erwägungsgrund 40 und die Begründung des deutschen Regierungsentwurfs sind sich einig, dass nur eine “wesentliche Veränderung” es zu einem neuen Produkt macht, das zum Zeitpunkt der Veränderung in Verkehr gebracht wird. Die Definition in Art. 4 Nr. 18 ist eng: Die Änderung muss die ursprüngliche Leistung, den Zweck oder die Art des Produkts über das hinaus verändern, was deine ursprüngliche Risikobewertung vorgesehen hat, und sie muss das Risiko verändern oder erhöhen. Ein neues Feature in einem Checkout-Plugin erfüllt das vermutlich nicht. Ein Umbau, der aus einem Anzeige-Plugin eines macht, das Kundendaten verarbeitet, vielleicht schon. Ob eine neue Major-Version, die als eigenes Store-Listing verkauft wird, als neues Produkt zählt, ist meines Wissens offen.

Agenturen, Freelancer und die Frage der Integration

Für eine Agentur ist die unangenehme Frage, wer eigentlich Hersteller ist.

Individualcode, den du schreibst und an einen Kunden lieferst, ist Software, die du im Rahmen einer Geschäftstätigkeit entwickelst und bereitstellst. Du bist ihr Hersteller. Wenn du einen kompletten Shop baust und dabei Plugins Dritter als Teil deiner Leistung integrierst, haftet nach Art. 8 Abs. 1 der Hersteller eines Produkts auch für Komponenten, die unter seiner Kontrolle integriert wurden, und alle Haftenden haften gesamtschuldnerisch (Art. 12 Abs. 1). Ich bin nicht sicher, ob ein Gericht ein geliefertes Shopware-Projekt als ein Produkt mit Komponenten in diesem Sinn behandeln würde, denn meist lizenziert der Händler die Plugins selbst. Meine Verträge würde ich aber nicht auf die Annahme bauen, dass es das nicht tut.

Die Shopware AG selbst ist ein anderer Fall. Laut Erwägungsgrund 18 stimmt ein Hersteller einer Integration nicht schon dadurch zu, dass er “die technische Möglichkeit der Integration oder Verbindung vorsieht”. Ein Plugin-System allein macht Shopware nicht für dein Plugin haftbar. Die AGB beschreiben den Store als einen von Shopware betriebenen Online-Marktplatz, und der Store verkauft nur an Unternehmen. Mehr als die Auffanghaftung eines Händlers, der den Hersteller nicht benennen kann (Art. 8 Abs. 3), sehe ich da nicht. Für einen Store-Hersteller mit EU-Adresse dürfte das keine Rolle spielen.

Auch das Patchen fremder Plugins verdient einen Gedanken. Wenn du Code eines Dritten so stark veränderst, dass es eine wesentliche Veränderung ist, und ihn dann bereitstellst, behandelt dich Art. 8 Abs. 2 als Hersteller dieses Produkts. Ein Zwei-Zeilen-Fix im Plugin eines Herstellers erreicht diese Schwelle nicht. Ein Fork mit neuer Funktionalität vielleicht schon.

Freelancer bekommen eine nützliche Klausel. Nach Art. 12 Abs. 2 hat ein Hersteller, der Software als Komponente integriert, keinen Rückgriff gegen ein Kleinst- oder Kleinunternehmen, das die fehlerhafte Komponente hergestellt hat, wenn er vertraglich darauf verzichtet hat. Automatisch passiert das nicht. Wenn du als Freelancer Plugins für eine Agentur baust, verlang diesen Verzicht im Vertrag. Wenn du die Agentur bist: Mit dem Verzicht trägst du das Risiko allein. Gegenüber der geschädigten Person ändert sich so oder so nichts.

Der Cyber Resilience Act ist die größere Änderung

Wenn ich Shopware-Plugin-Herstellern eine einzige Verordnung für dieses Jahr empfehlen müsste, wäre es der CRA, Verordnung (EU) 2024/2847. Seine Meldepflichten für aktiv ausgenutzte Schwachstellen gelten seit 11. September 2026. Die Hauptpflichten gelten ab 11. Dezember 2027: sichere Voreinstellungen, Schwachstellenmanagement, Sicherheitsupdates für einen festgelegten Supportzeitraum, technische Dokumentation und CE-Kennzeichnung.

Die Leitlinien der Kommission vom 27. Juli 2026 (C(2026) 5252) sagen, eigenständige Software falle in den Anwendungsbereich, wenn sie dem Nutzer bereitgestellt wird und auf seiner Seite läuft, und nennen Browser-Erweiterungen als Beispiel. Plugins werden nicht erwähnt. Ein kommerzielles Plugin, das auf dem Server des Händlers läuft, passt nach meiner Lesart auf diese Beschreibung. Eine Shopware-App, deren Logik komplett auf deinem Server läuft, ist näher an SaaS, und SaaS deckt der CRA größtenteils nicht ab.

Die Verbindung zur Produkthaftung läuft über Art. 10 Abs. 2 lit. b: Wer verbindliche Sicherheitsanforderungen nicht einhält, gegen den wird ein Fehler vermutet. Art. 7 Abs. 2 lit. f nennt “sicherheitsrelevante[ ] Cybersicherheitsanforderungen” ausdrücklich unter den Kriterien für die Fehlerhaftigkeit. Sobald der CRA gilt, startet ein Plugin, das seine Anforderungen nicht erfüllt, in jeden Produkthaftungsfall mit einer Vermutung gegen sich.

Eine Fußnote in den CRA-Leitlinien ist mir aufgefallen. Dort heißt es, “for the purposes of product liability law, computer code itself does not constitute a product”, mit Verweis auf Erwägungsgrund 13 der Produkthaftungsrichtlinie und dessen “reinen Quellcode von Software”. Shopware-Plugins werden als PHP-Quellcode ausgeliefert. Als Ausnahme würde ich das nicht lesen. Der Erwägungsgrund stellt Quellcode neben E-Books und Mediendateien, also als Information. Ein Plugin, das du installierst und ausführst, ist Software in Nutzung, und die nennt Erwägungsgrund 13 ein Produkt, unabhängig von der Art der Bereitstellung. Aber es ist ein Satz, den eines Tages ein Verteidiger zitieren wird.

Open Source in deinem Plugin

Deine composer.json zieht ein Dutzend Pakete, also betrifft dich das. Art. 2 Abs. 2 nimmt freie und quelloffene Software aus, “die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird”. Erwägungsgrund 15 sagt dann: Integriert ein Hersteller solche Software in ein kommerzielles Produkt, haftet der Hersteller, nicht der Open-Source-Entwickler.

Die Maintainer der Bibliotheken, die du nutzt, sind also raus, und du bist für alles drin. Ein Bug in einer Abhängigkeit, der Kundendaten beschädigt, ist aus Sicht der geschädigten Person dein Bug. Kostenlose Plugins sind auch nicht automatisch raus. Erwägungsgrund 14 holt Software zurück in den Anwendungsbereich, wenn sie “gegen einen Preis oder gegen personenbezogene Daten” bereitgestellt wird, die für mehr als Sicherheit, Kompatibilität oder Interoperabilität genutzt werden. Ein kostenloses Plugin, das existiert, um eine Bezahlversion oder ein SaaS-Abo zu verkaufen, wird meiner Einschätzung nach im Rahmen einer Geschäftstätigkeit bereitgestellt.

Wo Deutschland steht

Deutschland setzt die Richtlinie mit einem neuen, eigenständigen Produkthaftungsgesetz um, als Teil des “Gesetzes zur Modernisierung des Produkthaftungsrechts” (Bundestagsdrucksache 21/4297). Das Kabinett hat den Entwurf am 17. Dezember 2025 beschlossen, die erste Lesung war am 4. März 2026, und am 8. Oktober 2026 hat der Bundestag das Gesetz in der Fassung beschlossen, die sein Rechtsausschuss empfohlen hatte (Drucksache 21/8429). Der Bundesrat muss sich noch ein zweites Mal damit befassen, bevor es verkündet werden kann, und einen Termin dafür habe ich noch nicht gefunden. Inkrafttreten bleibt der 9. Dezember 2026.

Der Ausschuss hat wenig geändert, was für Softwarehersteller zählt. Seine Änderungen betreffen vor allem die Offenlegung von Beweismitteln. Gerichte können jetzt auch Dritte, etwa Marktüberwachungsbehörden, zur Herausgabe von Beweismitteln verpflichten (§ 19 Abs. 1). Und ein Beklagter, der um seine Geschäftsgeheimnisse fürchtet, kann ein gesondertes Verfahren beantragen, in dem zunächst ein vom Gericht bestellter, zur Geheimhaltung verpflichteter Sachverständiger das Material sichtet und nur die Prozessvertreter der Parteien Zugang bekommen (§ 19 Abs. 4). Für einen Plugin-Hersteller, dessen Quellcode als Beweismittel auf dem Tisch landet, ist dieser zweite Punkt der nützliche. Der Rest des Änderungspakets betrifft die elektronische Akte in der Justiz und eine Übergangsvorschrift zum Recht-auf-Reparatur-Gesetz.

Das Gesetz behält den Haftungsausschluss für Entwicklungsrisiken (§ 9 Abs. 1 Nr. 3) und streicht die Selbstbeteiligung von 500 € und die Höchstgrenze von 85 Millionen €. Die Begründung der Bundesregierung hält fest, dass beide Grenzen “derzeit in der Praxis kaum relevant” seien, weil deutsche Gerichte Produktfälle ohnehin meist nach § 823 BGB entscheiden. Das heißt auch: Die deliktische Haftung, die du schon hast, bleibt.

Im EU-Vergleich ist Deutschland im Zeitplan. Laut dem Tracker von Faegre Drinker vom September 2026 hatten zu diesem Zeitpunkt nur Ungarn und Kroatien ihre Umsetzung abgeschlossen.

Was ich vor Dezember tun würde

  1. Liste deine Plugins und Versionen auf und notiere, welche du nach dem 9. Dezember 2026 noch verkaufst oder in Betrieb nimmst. Die fallen unter die neuen Regeln.
  2. Prüfe, welche Plugins im Storefront oder im Kundenkonto mit Verbraucherdaten oder Uploads von Verbrauchern arbeiten. Dort erreicht dich die Richtlinie tatsächlich.
  3. Leg für jede Plugin-Version einen Supportzeitraum und ein End-of-Life-Datum fest und veröffentliche beides.
  4. Führe ein Log deiner Sicherheitsfixes: wann das Problem bekannt war, wann der Fix erschien, wie die Händler informiert wurden.
  5. Lies deine Haftpflichtpolice. Viele IT-Haftpflichtversicherungen decken Vermögensschäden, aber keine Produkthaftung, und der Makler FMP Fuchs weist darauf hin, dass Datenverlust oft eine Grauzone zwischen Sach- und Vermögensschaden ist. exali zum Beispiel verweist auf eine eigene Produkthaftpflichtversicherung.
  6. Agenturen: Klärt, wer das Risiko für integrierte Plugins Dritter trägt, und schreibt es in den Vertrag. Freelancer: Fragt nach dem Verzicht nach Art. 12 Abs. 2.
  7. Fang mit dem CRA an. Die Meldepflichten gelten schon, und Dezember 2027 ist vierzehn Monate entfernt.

Die Shopware AG hat, soweit ich finden konnte, nichts zur Produkthaftungsrichtlinie oder zum CRA für Extension-Partner veröffentlicht. Wenn du etwas von ihnen gesehen hast, im Partnerportal oder anderswo, würde ich das gern wissen.

Quellen

Ähnliche Artikel