Drupal Commerce Core: Zugriffslücke CVE-2026-118539 wird aktiv ausgenutzt
Das Drupal-Sicherheitsteam meldet seit dem 28. Oktober 2026 eine aktiv ausgenutzte Zugriffslücke im Modul Commerce Core (CVE-2026-118539). Die Lücke kann Shopbetreibern finanziell schaden. Abhilfe schaffen die Versionen 3.3.13 und 8.x-2.41, zusätzlich sollen Betreiber ihre Bestellungen auf Unstimmigkeiten prüfen.

Das Drupal-Sicherheitsteam hat am 28. Oktober 2026 die Mitteilung SA-CONTRIB-2026-254 zum Modul Commerce Core veröffentlicht. Die Zugriffslücke CVE-2026-118539 wird laut Mitteilung bereits aktiv ausgenutzt, korrigiert ist sie in den Versionen 3.3.13 und 8.x-2.41.
Betroffen sind nur Drupal-Seiten mit diesem Shop-Modul, Drupal ohne Commerce fällt nicht darunter. Shops sollten sofort aktualisieren und nicht auf das nächste Wartungsfenster warten, außerdem gehört eine Prüfung der Bestellungen dazu.
Was ist passiert?
Commerce Core stellt Warenkorb und Checkout bereit und bedient auch entkoppelte Anwendungen über Schnittstellen. Laut Mitteilung schützt das Modul bestimmte Routen und Entitätsfelder nicht ausreichend. Daraus entsteht eine Umgehung der Zugriffsprüfung, die dem Verkäufer finanziell schaden kann.
Welche Routen und Felder das sind, nennt die Mitteilung nicht. Auch zu den Angriffen selbst fehlen Angaben, etwa zur Zahl der Opfer oder zum genauen Ablauf. heise online griff die Warnung am 2. November auf.
Wer ist betroffen?
Anfällig sind alle Commerce-Core-Versionen unter 2.41 sowie die 3er-Reihe unter 3.3.13. Maßgeblich ist also die installierte Modulversion, nicht die Drupal-Version. Seiten ohne das Modul commerce sind von dieser Mitteilung nicht betroffen.
Wie kritisch ist das?
Drupal stuft die Lücke mit 21 von 25 Punkten als „Highly critical“ ein. Der Wert stammt aus dem eigenen Risikomodell des Projekts und ist kein CVSS-Wert. Die NVD führt zusätzlich eine Fremdbewertung mit CVSS 3.1 von 6,5, ebenfalls ohne nötige Anmeldung, und hat die Nummer selbst noch nicht bewertet. Die Einstufung beschreibt einen Angriff ohne besondere Komplexität und ohne Anmeldung, mit teilweisem Einfluss auf Vertraulichkeit und Integrität der Daten, und vermerkt einen vorhandenen Exploit. Angreifbar sind danach alle Konfigurationen des Moduls.
Es geht um eine Umgehung von Zugriffsrechten, von Codeausführung auf dem Server ist in der Mitteilung keine Rede. Drupal nennt mögliche finanzielle Schäden für den Verkäufer und verlangt eine Prüfung der Bestellungen. Das deutet aus Sicht der Redaktion auf manipulierte Bestellvorgänge hin, die genaue Wirkung lässt das Team aber offen. Im CISA-Katalog ausgenutzter Lücken fehlte die Nummer im Stand vom 30. Oktober, das ändert nichts an der Aussage des Drupal-Teams.
Was sollten Admins jetzt tun?
- Inventar: Prüfen, ob und in welcher Version das Modul läuft, zum Beispiel über die Update-Übersicht von Drupal oder
composer show drupal/commerce. - Patchstand: Die 3er-Reihe auf 3.3.13 heben, ältere Installationen auf 8.x-2.41.
- Bestellungen: Wie von Drupal gefordert auf Unstimmigkeiten prüfen, etwa Beträge, Status und Zahlungseingang im Abgleich mit dem Zahlungsanbieter.
- Logs: Zugriffe auf Shop- und API-Routen möglichst weit zurück sichten, soweit Protokolle vorliegen. Seit wann die Angriffe laufen, nennt Drupal nicht.
- Backup: Vor dem Update Datenbank und Dateien sichern, damit auffällige Bestände später verglichen werden können.
Einordnung für Unternehmen
Bei Shops endet die Arbeit nicht mit dem Update. Weil die Lücke laut Drupal bereits angegriffen wird, können falsche Bestellungen schon im System liegen, und die landen schlimmstenfalls in Buchhaltung und Versand. Sinnvoll ist deshalb ein Abgleich mit dem Zahlungsanbieter für die Zeit vor dem Update, und zwar so weit zurück wie möglich. Der Fall betrifft nur einen Teil der Drupal-Installationen, dort aber das Geschäft direkt.
Passende Anleitungen auf S-EDV
- borgmatic im Docker-Container: automatisierte Server-Backups mit BorgBackup
- CrowdSec mit Docker installieren: Community-IDS/IPS für Ihren Linux-Server


