Drupal Commerce Core: Lücke wird ausgenutzt, jetzt auf 3.3.13 aktualisieren

Angreifer nutzen eine hochkritische Schwachstelle in Drupal Commerce Core aus, dem Warenkorb-Modul für das Content-Management-System Drupal, um Bestellungen aufzugeben, die sie nie bezahlt haben. Das Sicherheitsteam von Drupal veröffentlichte am 28. Oktober 2026 das Advisory SA-CONTRIB-2026-254 und schreibt, der Fehler werde „aktiv in freier Wildbahn ausgenutzt“. Jeder Shop auf Basis des Moduls braucht diese Woche zwei Dinge: das Update auf 3.3.13 oder 8.x-2.41 und eine Prüfung der jüngsten Bestellungen.

Die Lücke trägt die Kennung CVE-2026-118539. Drupal bewertet sie mit 21 von 25 Punkten, der Stufe „Highly critical“, mit dem Vektor AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. Auf Deutsch: Es braucht weder Login noch besondere Rechte, Daten lassen sich lesen und ändern, und ein Exploit existiert.

Was ein Angreifer mit der Lücke anstellen kann

Das Modul „schützt bestimmte Routen und Entitätsfelder nicht ausreichend“, heißt es im Advisory. Das ist eine Zugriffsumgehung: Ein Besucher erreicht Seiten und Datenfelder, die eigentlich gesperrt sein sollten. BleepingComputer berichtet, ein nicht angemeldeter Angreifer könne damit die Zugriffsregeln des Shops umgehen.

Centarro, das Unternehmen hinter Drupal Commerce, beschrieb die Angriffe am 29. Oktober in einem Beitrag seines CEO Ryan Szrama. Händler beobachteten vier Arten von Missbrauch:

• Bestellungen, die direkt und unter Umgehung des Checkouts angelegt wurden, sodass die Bestellung existiert, aber nie bezahlt wurde.
• Bestellungen, die in der Bestellverwaltung als bezahlt erscheinen, ohne dass eine Zahlung dahintersteht, vor allem auf Seiten mit freigeschaltetem JSON:API-Webdienst.
• Vor dem Checkout gesenkte Produktpreise.
• Rabatte, Gebühren oder andere Anpassungen, die weder ein Mitarbeiter noch eine Aktion hinzugefügt hat.

„Wir haben zwei Berichte über Versuche böswilliger Nutzer erhalten, betrügerische Bestellungen aufzugeben“, schrieb Szrama. Manche Bestellungen hatten offensichtlich falsche Preise wie 0,01 Dollar. Andere nutzten normale Preise. „Derzeit gehen wir nicht davon aus, dass es skriptgesteuert war oder über die ersten Seiten hinaus ausgenutzt wurde“, ergänzte er. Das Drupal Security Team koordinierte am 28. Oktober Test, Paketierung und Veröffentlichung der Korrektur.

Wer betroffen ist und was zu installieren ist

Drupal nennt Dan Puccetti, Marcus Johansson und Robert Snyder als Melder der Lücke. Sechs Personen, darunter Szrama, werden für die Korrektur genannt. BleepingComputer beziffert die Installationsbasis des Moduls unter Berufung auf die Projektseite auf drupal.org mit mehr als 42.000 Websites.

Zweig	Betroffene Versionen	Korrigierte Version	Drupal-Voraussetzung (laut Rescana)
Commerce Core 3.x	3.0.0 bis ausschließlich 3.3.13	3.3.13	Drupal 10.3 oder neuer, oder Drupal 11
Commerce Core 8.x-2.x	Jede Version vor 8.x-2.41	8.x-2.41	Drupal 9.3 oder neuer, oder Drupal 10

Mit Commerce Core ist es nicht getan. Laut Centarro erhielten Commerce API, Commerce License, Commerce Shipping und Commerce Stripe am 28. Oktober ebenfalls Sicherheitsreleases und sollten gleichzeitig aktualisiert werden. Rescana weist darauf hin, dass Drupal parallel fünf niedriger eingestufte Commerce-Core-Advisories veröffentlichte, SA-CONTRIB-2026-255 bis 259. Ein separates Stripe-Advisory, SA-CONTRIB-2026-263, ist als kritisch eingestuft und könnte es einem Angreifer erlauben, eine Bestellung ohne Zahlung als bezahlt zu markieren.

Centarro erinnert Nutzer von 8.x-2.x außerdem daran, dass der Support für diesen Zweig mit dem Erscheinen von Drupal 12 endet. „Wir empfehlen, so bald wie möglich auf 3.x umzusteigen“, heißt es im Beitrag.

Wie lange die Lücke offen stand

Der Fehler ist alt. Laut Centarro waren Exploits auf Seiten mit JSON:API seit Commerce Core 8.x-2.18 „theoretisch möglich“, veröffentlicht am 26. Mai 2020. Für alle anderen Seiten öffnete sich das Fenster mit 8.x-2.25 am 30. Juni 2021. Centarro versteht diese Daten als frühestmögliche Zeitpunkte, nicht als bestätigte Angriffsdaten.

Im Katalog der bekanntermaßen ausgenutzten Schwachstellen (KEV) der US-Behörde CISA stand die Lücke laut Rescana in der Ausgabe vom 29. Oktober nicht. Das Etikett „aktiv ausgenutzt“ stammt von Drupal und Centarro selbst. Die CISA hat über die Jahre fünf Drupal-Lücken als ausgenutzt markiert, berichtet BleepingComputer, zuletzt im Mai 2026 eine SQL-Injection-Lücke, CVE-2026-9082. Der Drupal-Kern selbst hat erst vor zwei Wochen eine kritische Codeausführungslücke in Field UI geschlossen.

So prüfen Sie Ihre Bestellungen

Der Patch schließt die Tür. Bereits durch sie aufgegebene Bestellungen macht er nicht rückgängig. Laut Drupal-Advisory „sollten Seiten ihre Bestellungen auf Unstimmigkeiten prüfen“. Centarros Beitrag nennt vier Datenbankprüfungen, jede als Abfrage, die Shop-Betreiber ausführen können:

1. Bestellungen, die außerhalb des Checkouts angelegt wurden und noch einen offenen Betrag haben.
2. Bestellungen, deren verbuchter Zahlbetrag höher ist als die abgeschlossenen Zahlungen in den Unterlagen.
3. Bestellpositionen mit überschriebenem Stückpreis. Centarro merkt an, die erste Prüfung übersehe einen auf 0,01 Dollar gesenkten und dann bezahlten Preis.
4. Anpassungen wie eigene Gebühren oder Rabatte, die nicht aus einer Aktion stammen.

Ein Treffer ist kein Beweis für Betrug. Auch von Mitarbeitern angelegte Bestellungen und Produkte nach dem Prinzip „Zahl, was du willst“ passen ins Muster, deshalb braucht jede markierte Bestellung einen menschlichen Blick. Rescana ergänzt, ein Abgleich der IP-Adressen und Zeiten der markierten Bestellungen mit den Zugriffsprotokollen normaler Checkout-Pfade helfe, beides zu trennen.

Centarros Betriebsrat ist deutlicher: Versenden Sie eine Bestellung nicht, weil sie aufgegeben oder der Checkout abgeschlossen wurde. Bestätigen Sie zuerst die Zahlung. Und wenn Ihre Seite JSON:API nicht für Änderungen braucht, stellen Sie es auf Nur-Lesen.

Was das für Entwickler bedeutet

• Heute patchen, dann bis 2020 zurück prüfen. Die Korrektur ist ein gewöhnliches Composer-Update auf 3.3.13 oder 8.x-2.41 plus die vier Begleitmodule. Die Prüfung ist der langsame Teil. Wenn Ihre Seite JSON:API seit Mai 2020 freigeschaltet hat, müssen die vier Abfragen über fünf Jahre Bestellungen laufen, nicht über die letzte Woche.
• „Als bezahlt angezeigt“ ist eine Behauptung, keine Tatsache. Die zweite Angriffsart erzeugt Bestellungen, die der Verwaltungsbildschirm als bezahlt meldet, ohne Zahlungsentität dahinter. Jede Versandautomatik, die allein auf den Bestellstatus hört, hat einem Feld vertraut, das der Angreifer setzen konnte. Prüfen Sie, ob Ihr Versandschritt Zahlungsdatensätze liest, nicht den Bestellstatus.
• Headless-Shops tragen mehr Risiko. Beide an JSON:API gebundenen Angriffsarten und das frühere Startdatum 2020 gelten für entkoppelte Seiten. Liefert die API nur Produktdaten an ein Frontend, stellen Sie sie jetzt auf Nur-Lesen, unabhängig von Ihrer Drupal-Version.
• Die Begleit-Advisories im Blick behalten. Die separate kritische Korrektur für Commerce Stripe betrifft alle, die Stripe als Zahlungsanbieter nutzen. Aktualisieren Sie sie im selben Deployment wie Commerce Core.
• Alles Auffällige melden. Centarro schreibt, man „prüfe lieber Fehlalarme oder doppelte Meldungen, als von einer möglichen Schwachstelle nichts zu erfahren“. Zwei Händlerberichte fanden diesen Fehler nach fünf Jahren im Code.