Sylius Mollie Plugin: Payment-Webhook-Forgery und Order-ID-Enumeration — Fix in 2.2.9 / 3.2.5 / 3.3.2

TL;DR — 90 Sekunden

Betroffen?

sylius/mollie-plugin (offizielles Sylius-Payment-Plugin für Mollie) in den Versionen 2.2.8, 3.2.4 und 3.3.1 sowie älteren Ständen. Betroffen sind der Payment-Webhook-Controller sowie die QR-Code- und Thank-you-Endpunkte des Checkouts.

Risiko?

Zwei GitHub-Security-Advisories (GHSA-rc52-c4hv-w89p, High: Payment-Status-Forgery über den Webhook; GHSA-x83g-979r-f5fh, Moderate: Order-ID-Enumeration mit PII-Abgriff und DoS-Potenzial). CVE-Nummern stehen zum Zeitpunkt dieses Artikels noch aus.

Sofortmaßnahme?

Auf sylius/mollie-plugin ≥2.2.9, ≥3.2.5 bzw. ≥3.3.2 aktualisieren. Wer nicht sofort updaten kann, deckt Webhook- und Order-Endpunkte per Controller-Decoration ab (siehe Mitigation).

Empfehlung?

Wer noch die verwaisten Vorgänger-Pakete bitbag/mollie-plugin oder mollie/sylius-plugin einsetzt, migriert zusätzlich auf sylius/mollie-plugin — diese Pakete werden nicht mehr gepflegt.

Kritikalität?

mittel (Hero-Badge) — echtes Betrugsrisiko im Payment-Pfad und PII-Exposure, aber keine bestätigte aktive Ausnutzung, kein RCE.

Was ist das Problem?

Am 9. Juli 2026 hat das Sylius-Projekt einen Security-Release für das offizielle Mollie-Payment-Plugin (sylius/mollie-plugin) veröffentlicht. Zwei unabhängige, aber im selben Modul verwurzelte Schwachstellen betreffen den Zahlungs- und Bestell-Pfad von Sylius-Shops, die Mollie als Payment-Provider nutzen.

Der Kernfehler des ersten Advisories (GHSA-rc52-c4hv-w89p): Der Payment-Webhook-Controller nimmt zwei nutzergesteuerte Parameter entgegen, ohne zu prüfen, dass die referenzierte Mollie-Payment-ID tatsächlich zur betroffenen Bestellung gehört. Ein Angreifer kann eine eigene, niedrigwertige Bestellung real bezahlen, die dabei entstehende (jetzt bezahlte) Mollie-Payment-ID abgreifen und sie gegen beliebige andere Order-IDs replayen — die fremde Bestellung wird ohne tatsächliche Zahlung als bezahlt markiert.

Das zweite Advisory (GHSA-x83g-979r-f5fh) betrifft die Shop-Endpunkte für QR-Code-Anzeige und Thank-you-Redirect: Beide lösen Bestellungen über eine fortlaufende, vorhersehbare ID auf, ohne zu prüfen, ob die anfragende Session überhaupt Zugriff auf diese Bestellung haben darf.

Wer ist betroffen?

Betroffen sind alle Sylius-Shops (2.x und 3.x), die Mollie als Zahlungsmethode über das offizielle Plugin einbinden und öffentlich erreichbare Checkout- bzw. Webhook-Endpunkte betreiben — praktisch jeder produktive Mollie-Shop. Wer eines der beiden abgekündigten Fremd-Pakete (bitbag/mollie-plugin, mollie/sylius-plugin) einsetzt, ist zusätzlich vom fehlenden Support betroffen und sollte den Wechsel auf das offizielle Paket mit einplanen.

Auswirkungen

GHSA-rc52-c4hv-w89p erlaubt handfesten Zahlungsbetrug: Bestellungen werden als bezahlt gebucht, ohne dass Geld beim Händler eingeht — mit direkten finanziellen Verlusten und potenziellem Warenversand ohne Gegenwert. GHSA-x83g-979r-f5fh erlaubt das Durchnummerieren von Order-IDs, wodurch Namen und E-Mail-Adressen von Kunden im großen Stil abgegriffen werden können; die wiederholten Anfragen an die betroffenen Endpunkte eignen sich zudem als unauthentifizierter DoS-Vektor gegen den Checkout.

Beide Lücken erfordern keinen privilegierten Zugriff — ein normaler Shop-Zugang (im Fall der Payment-Forgery: die Fähigkeit, selbst eine reguläre Bestellung aufzugeben) reicht aus.

Mitigation / Sofortmaßnahmen

Hinweis: Details zu Controller-Namen und exakten Routen wurden im offiziellen Sylius-Advisory nicht vollständig veröffentlicht; die folgenden Schritte fassen die offizielle Empfehlung zusammen und sollten gegen die GHSA-Advisories und den Plugin-Changelog abgeglichen werden.

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie sylius/mollie-plugin in einer Version unter 2.2.9 (2.x), 3.2.5 (3.2.x) oder 3.3.2 (3.3.x) produktiv betreiben.
• Mit Priorität prüfen, wenn … Sie noch bitbag/mollie-plugin oder mollie/sylius-plugin im Einsatz haben — diese Pakete erhalten keinen Fix und müssen migriert werden.
• Nur beobachten, wenn … Sie bereits auf sylius/mollie-plugin ≥2.2.9 / ≥3.2.5 / ≥3.3.2 sind und Mollie nicht als Zahlungsmethode nutzen.

Schritt 1 — Plugin-Version aktualisieren

# Version prüfen
composer show sylius/mollie-plugin | grep versions
# auf die gepatchte Version aktualisieren (Beispiel für die 3.3-Reihe)
composer require sylius/mollie-plugin:^3.3.2

Schritt 2 — abgekündigte Fremd-Pakete ablösen

# statt bitbag/mollie-plugin bzw. mollie/sylius-plugin:
composer remove bitbag/mollie-plugin
composer require sylius/mollie-plugin
# danach Bundle-Registrierung, Service-Prefix, Template-Overrides und
# Namespace-Referenzen gemäß Migrationsleitfaden anpassen

Schritt 3 — Workaround, falls ein sofortiges Update nicht möglich ist

// WebhookController per Decorator-Pattern absichern:
// vor der Statusübernahme prüfen, dass die eingehende Mollie-Payment-ID
// tatsächlich der in der Order gespeicherten Payment-ID entspricht
// (services.yaml: Decorator auf den bestehenden Webhook-Controller registrieren)

// QrCode- und Thank-you-Controller per Decorator absichern:
// vor der Order-Auslieferung prüfen, dass die aufrufende Session/Token
// Eigentümer der angefragten Order-ID ist

Schritt 4 — bereits erfolgte Manipulationen prüfen

# Bestellungen mit Status "bezahlt" gegen tatsächliche Mollie-Transaktionen abgleichen
# (Anzahl bezahlter Bestellungen vs. Anzahl abgeschlossener Mollie-Payments je Zeitraum)

Detection / Prüfung

Plugin-Version prüfen

composer show sylius/mollie-plugin
composer show bitbag/mollie-plugin 2>/dev/null
composer show mollie/sylius-plugin 2>/dev/null

Auffällige Webhook-Aufrufe in den Logs suchen

# Mehrfachverwendung derselben Mollie-Payment-ID gegen unterschiedliche Order-IDs
grep "mollie" access.log | grep -oE "payment_id=[a-zA-Z0-9_]+" | sort | uniq -c | sort -rn | head -20

Order-Enumeration erkennen

# sequentielle Order-ID-Anfragen von derselben Quelle in kurzer Zeit
grep -E "/(qr-code|thank-you)/" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Laufzeit-Indikatoren

- Bestellungen mit Status "bezahlt", denen keine abgeschlossene Mollie-Transaktion zugeordnet werden kann
- ungewöhnlich viele 200er-Antworten auf sequentiell inkrementierte Order-IDs von derselben IP
- Support-Anfragen zu Bestellungen, die als bezahlt markiert sind, aber nie beglichen wurden

Betreiberempfehlung

Jetzt handeln: Wenn Sie einen produktiven Sylius-Shop mit Mollie als Zahlungsmethode betreiben, aktualisieren Sie sylius/mollie-plugin diese Woche auf die gepatchte Version — die Payment-Forgery ist ein direktes Betrugsrisiko mit Bilanzwirkung, kein theoretisches Szenario.

Priorität: Wer noch bitbag/mollie-plugin oder mollie/sylius-plugin einsetzt, plant die Migration auf das offizielle Paket ein, unabhängig von dieser konkreten Lücke — verwaiste Zahlungs-Integrationen sind ein wiederkehrendes Risiko.

Beobachten: Shops ohne Mollie-Integration oder bereits auf den gepatchten Versionen sind nicht akut betroffen, sollten den Abgleich bezahlter Bestellungen gegen Mollie-Transaktionen aber als Regelprüfung etablieren.

Fazit

Beide Lücken folgen einem vertrauten Muster in Payment-Integrationen: Webhook- und Rückkehr-Endpunkte, die dem externen Payment-Provider mehr vertrauen als der eigenen Datenbank. Der Fix ist unkompliziert — ein Versions-Update —, die Konsequenz eines ausbleibenden Updates ist es nicht: direkter finanzieller Schaden und Datenabfluss. Wer Mollie über Sylius abwickelt, sollte den Patch diese Woche einspielen und die Migration weg von den abgekündigten Fremd-Paketen als Gelegenheit mitnehmen.

Quellen

• Sylius — MolliePlugin: Security blog post – 2.2.9, 3.2.5 and 3.3.2 (09.07.2026)
• GitHub Security Advisory — GHSA-rc52-c4hv-w89p (Payment Status Forgery)
• GitHub Security Advisory — GHSA-x83g-979r-f5fh (Customer Data Exposure via Order ID Enumeration)
• Packagist — sylius/mollie-plugin