7,6 Prozent des deutschen Online-Umsatzes laufen über Kreditkarte und Wallet-Zahlungen, die Händler über Stripe abwickeln — und genau diese Zahlstrecke hat jetzt zum zweiten Mal innerhalb eines Monats ein Sicherheitsproblem. Am 6. August 2026 hat Automattic ein Sicherheitsupdate für Stripe for WooCommerce veröffentlicht. Betroffen sind die Versionen 9.7.0 bis 10.8.4, also praktisch jeder Shop, der das Plugin in den letzten anderthalb Jahren installiert und nicht auf dem aktuellsten Stand gehalten hat. Die gepatchte Version heißt 10.8.5 — und wer glaubt, mit dem Juli-Patch auf 10.8.4 schon erledigt zu haben, irrt.
Der Tonfall des offiziellen Advisories ist bemerkenswert nüchtern. Die Lücken wurden durch interne Tests bei Automattic gefunden, nicht durch einen externen Angriff. Es gebe keine Hinweise auf Ausnutzung und keine Hinweise darauf, dass Shop-, Kunden- oder Zahlungsdaten abgegriffen wurden. Trotzdem ordnet WooCommerce das schwerste der behobenen Probleme so ein: Unter bestimmten Umständen könne ein betroffener Shop komplett unerreichbar werden. Kein Datenleck, aber Denial of Service — und für einen Händler ist ein toter Checkout im Sommergeschäft wirtschaftlich fast so schlimm wie ein Datendiebstahl.
Was genau ist passiert — und warum schweigt WooCommerce zu den Details?
Technische Details zu den Schwachstellen hält Automattic bewusst zurück. Das ist keine Geheimniskrämerei, sondern Standard bei Sicherheitsadvisories: Solange ein relevanter Teil der installierten Basis ungepatcht ist, wäre jede öffentliche Beschreibung der Lücke eine Anleitung für Angreifer. Erst wenn die Update-Quote hoch genug ist, folgen üblicherweise die CVE-Einträge mit voller Beschreibung.
Bekannt ist die betroffene Spanne. Zwölf Release-Linien bekommen parallel gepatchte Builds, damit Händler nicht gezwungen sind, für den Sicherheitsfix gleich einen großen Versionssprung mitzumachen. Wer auf 9.7.x festhängt, bekommt 9.7.2, wer auf 10.3.x läuft, steigt auf 10.3.2 — und so weiter bis zur aktuellen Linie 10.8.x, die mit 10.8.5 geschlossen wird. Diese Backport-Strategie ist aufwendig und keineswegs selbstverständlich im WordPress-Ökosystem. Sie zeigt, wie ernst Automattic die Lage nimmt.
9.7.0 bis 10.8.4 — das ist die betroffene Versionsbandbreite. Alles davor gilt laut Advisory als nicht betroffen, alles danach ist sauber. Die Wahrscheinlichkeit, dass ein aktiv betriebener Shop in dieser Spanne liegt, ist hoch: Stripe for WooCommerce ist mit über einer Million aktiver Installationen eines der meistgenutzten Zahlungs-Plugins im WordPress-Verzeichnis.
Warum ist das Update auch für Juli-Patcher Pflicht?
Hier liegt der eigentliche Haken der Geschichte. Am 14. Juli 2026 musste WooCommerce bereits einmal patchen: eine Zahlungsvalidierungs-Schwäche im Adaptive-Pricing-Feature, gemeldet über HackerOne, die dazu führen konnte, dass der bei Stripe verarbeitete Betrag vom WooCommerce-Bestellwert abwich. Damals rollten die Fixes 10.6.2, 10.7.1 und 10.8.4 aus. Viele Agenturen und Hoster haben danach Haken drangemacht — zu Recht, aber zu früh.
Das August-Update ist ein eigenständiger Vorgang. Es ersetzt den Juli-Patch nicht, sondern setzt ihn voraus, und die damaligen Zielversionen gehören selbst zu den jetzt betroffenen Releases. Konkret: Ein Shop auf 10.8.4 gilt wieder als verwundbar und muss auf 10.8.5. Wer das ignoriert, weil er sich auf den Stand von vor vier Wochen beruft, schützt sich gegen gestern, nicht gegen heute.
Diese zweite Patch-Welle innerhalb eines Monats ist kein Zufall. Sie ist das sichtbare Ergebnis einer internen Sicherheitsprüfung, die Automattic offenbar nach dem HackerOne-Fund im Juli angestoßen hat. Das ist die gute Nachricht — und zugleich ein warnendes Signal über die Codebasis. Ein Plugin, das Zahlungen verarbeitet, bei dem interne Tests gleich mehrere sicherheitsrelevante Probleme zutage fördern, hat eine Hygiene-Frage zu beantworten.
Ein toter Checkout kostet Geld, noch bevor irgendwo Daten abfließen. Das schwerste Problem in diesem Update kann den ganzen Shop offline nehmen — das ist kein IT-Risiko, das ist ein Umsatzrisiko.
Wie groß ist das Risiko für deutsche WooCommerce-Händler?
Für den DACH-Markt hat die Sache eine besondere Schärfe, und sie hängt mit der Struktur der hiesigen Shop-Landschaft zusammen. WooCommerce ist im deutschsprachigen Mittelstand stark vertreten — von der Manufaktur, die ihre Ersatzteile selbst verkauft, bis zum Agentur-betreuten Marken-Shop. Viele dieser Installationen werden nicht vom Händler selbst gepflegt, sondern von Agenturen oder Hostern, die Dutzende Kundenshops im Wartungsvertrag haben.
Genau dort entsteht die gefährlichste Lücke: nicht im Code, sondern im Prozess. Ein Sicherheitsadvisory, das an einem Donnerstag im August erscheint, konkurriert mit Sommerurlauben, reduzierter Besetzung und Wartungsfenstern, die monatlich statt täglich geplant sind. Die Verwundbarkeits-Statistiken von Wordfence und Sucuri zeigen seit Jahren dasselbe Muster — die meisten kompromittierten WordPress-Seiten liefen zum Zeitpunkt des Angriffs mit Plugins, für die ein Patch bereits verfügbar war. Nicht Wochen alt. Tage.
Rechnet man das Denial-of-Service-Szenario durch, wird es konkret. Ein mittelgroßer deutscher WooCommerce-Shop mit 30.000 Euro Tagesumsatz, der wegen einer ausgenutzten Lücke 48 Stunden offline ist, verliert nicht nur die Bestellungen dieser zwei Tage. Er verliert Wiederkehrrate, zahlt Agentur-Notfallstunden und erklärt Kunden per Mail, warum ihre Kreditkartenzahlung nicht durchging. Die ehrliche Antwort auf die Frage nach dem Risiko lautet deshalb nicht „moderat, keine Ausnutzung bekannt“, sondern: Das Risiko wächst mit jedem Tag, an dem der Patch nicht eingespielt ist.
- Shop-Version prüfen: Plugins → Installierte Plugins → Stripe for WooCommerce. Alles zwischen 9.7.0 und 10.8.4 ist betroffen.
- Auf 10.8.5 aktualisieren — oder, wer eine ältere Linie halten muss, auf den jeweiligen gepatchten Build dieser Linie (10.7.2, 10.6.3, 10.5.4 und so weiter).
- Danach den Checkout testen: Stripe-Zahlarten müssen laden, eine Testbestellung muss durchlaufen. Das Advisory empfiehlt das ausdrücklich — und genau dieser Schritt fängt die Probleme ab, bevor Kunden sie melden.
Was sollten Agenturen und Hoster jetzt anders machen?
Einmal patchen ist die leichte Übung. Die schwierige ist strukturell. Wer zwanzig oder fünfzig Kundenshops betreut, braucht kein Ad-hoc-Update nach Mail-Eingang, sondern einen Prozess, der Sicherheitsadvisories der Kern-Plugins innerhalb von 24 Stunden in Tickets übersetzt. Der WooCommerce Developer Blog, auf dem dieses Advisory erschienen ist, gehört dafür in jedes Monitoring — neben Wordfence Intelligence und dem Stripe-Status.
Zweitens gehört die Frage auf den Tisch, warum ein Shop überhaupt noch auf 9.7.x läuft. Backport-Patches sind ein Entgegenkommen von Automattic, keine Einladung zum Dauerzustand. Jede alte Release-Linie multipliziert den Testaufwand beim nächsten WooCommerce-Core-Update und den Erklärungsbedarf beim nächsten Vorfall. Das August-Update ist ein guter Anlass, die veralteten Linien in der eigenen Flotte zu zählen.
Drittens: Dokumentation. Für Agenturen mit Wartungsverträgen ist das Advisory zugleich ein Haftungsthema. Wer nachweisen kann, wann er über die Lücke informiert war und wann der Patch eingespielt wurde, steht im Streitfall besser da als jemand, der auf Erinnerung setzt. Ein Zweizeiler im Ticket-System pro Shop genügt.
Ein Muster, das bleibt
Zoomt man heraus, ist der August-Patch die dritte sicherheitsrelevante Episode rund um Stripe-Integrationen im WooCommerce-Universum allein in diesem Sommer: die Auth-Bypass-Lücke im Juni, die im Express-Checkout beliebige Bestellungen auf „fehlgeschlagen“ setzen konnte, der Adaptive-Pricing-Fix im Juli, jetzt die intern entdeckten Probleme im August. Zahlungs-Plugins sind die am härtesten angegriffene Schicht jedes Shops — sie sitzen genau da, wo Geld fließt und wo ein Fehler direkt in Umsatz oder Vertrauen übersetzt wird.
Automattic reagiert diesmal so, wie man es sich wünscht: früh, mit Backports für zwölf Linien, mit klaren Handlungsanweisungen und ohne Panik-Vokabular. Das verdient Anerkennung. Aber die Frequenz der Vorfälle legt eine unbequeme Frage nahe, die sich Händler und Agenturen selbst beantworten müssen: Wer seinen Umsatz über ein einziges Zahlungs-Plugin schleust, trägt dessen Sicherheitsbilanz mit. Ein zweiter Zahlungsdienst im Fallback, ein getestetes Wiederanlauf-Szenario für den Ernstfall und ein Patch-Prozess, der nicht auf den nächsten Wartungstermin wartet — das sind keine Luxusmaßnahmen mehr, sondern die Baseline für 2026. Der nächste Patch kommt bestimmt. Die Frage ist nur, ob der Shop darauf vorbereitet ist oder darauf wartet.