Sylius Security-Release 2.0.18 / 2.1.15 / 2.2.6 — drei Lücken im Shop- und Payment-API-Pfad

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Sylius Security-Release am 02.06.2026 mit drei Advisories, alle im Shop-/Payment-API-Pfad: GHSA-5597-7rmh-97q5 (Cart-LiveComponent ändert/löscht abgeschlossene Order), GHSA-mr9r-h354-966r (IDOR auf Payment-Request-Endpoints), GHSA-6955-hrm5-c4qp (Channel-Bypass bei der Zahlart). Behoben in 2.0.18, 2.1.15, 2.2.6.

Wie schwer?

Moderate. Höchster Einzelwert CVSS 6.5 (GHSA-5597, Integritäts-/Datenverlust an bezahlten Bestellungen), dann CVSS 4.3 (Channel-Bypass) und der IDOR (Moderate, ohne veröffentlichten Score). Keine CVE-Nummern, keine bekannte aktive Ausnutzung, kein öffentlicher PoC Stand 02.06.

Welche Versionen sind betroffen?

Alle drei: >=2.0.0 <2.0.18, >=2.1.0 <2.1.15, >=2.2.0 <2.2.6. Behoben in 2.0.18 / 2.1.15 / 2.2.6 und höher.

Bin ich als Moselwal-Kunde betroffen?

Betroffen, wenn Sie einen Sylius-Shop in einer der genannten Versionen betreiben. Der IDOR und der Channel-Bypass betreffen die Shop-API (API Platform); die Cart-Race betrifft das LiveComponent-Frontend. Wer die Shop-API oder die LiveComponents nutzt — also praktisch jeder Standard-Shop — gehört in den Patch-Lauf.

Sofort-Mitigation?

composer update sylius/sylius auf 2.0.18 / 2.1.15 / 2.2.6 (je nach Minor-Linie), danach bin/console cache:clear. Wer nicht sofort upgraden kann: für jede der drei Lücken gibt es im Advisory einen dokumentierten Workaround per Service-Decorator/Override in src/ plus config/services.yaml.

Kritikalität?

Siehe Hero-Badge medium. Operativer Patch-Druck im Wochenfenster; keine akute Ausnutzungs-Lage, aber drei Access-Control-/Workflow-Defekte direkt am Bezahl-Pfad sind nichts, was man liegen lässt.

 

Was ist passiert

Sylius hat am 2. Juni 2026 drei Security-Advisories veröffentlicht und parallel die Wartungs-Releases 2.0.18, 2.1.15 und 2.2.6 ausgeliefert. Alle drei Lücken sitzen im selben funktionalen Bereich: dem Shop-Frontend und der Shop-API rund um Warenkorb und Bezahlung. Keine der drei hat eine CVE-Nummer erhalten; sie werden über ihre GitHub-Security-Advisory-IDs geführt.

Die erste und schwerste ist GHSA-5597-7rmh-97q5 (CVSS 6.5). Sie betrifft das Cart-FormComponent, ein Symfony-UX-LiveComponent. Das Szenario: Ein Kunde hat die Warenkorb-Seite offen, während die Bestellung im Hintergrund abgeschlossen wird, etwa weil die Zahlung in einem anderen Tab finalisiert oder der Status im Backend geändert wird. Das LiveComponent merkt davon nichts und zeigt weiter den alten Warenkorb. Klickt der Kunde nun auf „Warenkorb leeren“, ruft clearCart() ein manager->remove() auf der bereits abgeschlossenen Bestellung auf — die Order wird dauerhaft aus der Datenbank gelöscht. „Position entfernen“ und „Menge ändern“ mutieren die abgeschlossene Bestellung entsprechend. Der Effekt ist irreversibler Verlust oder Verfälschung von Bestelldaten, die eigentlich schon verbindlich und bezahlt waren; der Pfad lässt sich von einem authentifizierten Kunden auch absichtlich auslösen.

Die zweite ist GHSA-mr9r-h354-966r (IDOR, Moderate). Die Endpoints GET und PUT /api/v2/shop/payment-requests/{hash} schlagen den Payment-Request allein über den Hash aus der URL nach, ohne Eigentümer-Prüfung gegen den authentifizierten Kunden oder die zugrunde liegende Bestellung. Wer einen Payment-Request-Hash kennt, kann den Request lesen und über die payment-IRI in der Antwort den tokenValue der Bestellung rekonstruieren — und damit auf die vollständige Order zugreifen (Positionen, Adressen, Kunden-E-Mail, Summen). Per PUT lassen sich zudem target_path und after_path überschreiben, also die Felder, mit denen das Frontend nach der Zahlung weiterleitet; ein Angreifer biegt den Redirect damit auf eine eigene URL um. Der zugehörige Creation-Endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests teilt den Fehler, weil er die Ziel-Bestellung ebenfalls nur aus dem tokenValue auflöst.

Die dritte ist GHSA-6955-hrm5-c4qp (CVSS 4.3, Channel-Bypass). Der Endpoint PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId}, mit dem ein angemeldeter Kunde die Zahlart einer platzierten, aber noch nicht bezahlten Bestellung ändert, prüft nicht, ob die gewählte Zahlart im Channel der Bestellung überhaupt aktiviert ist. Der äquivalente Checkout-Endpoint lehnt channelfremde Zahlarten korrekt mit HTTP 422 ab; der Account-Endpoint nimmt sie still mit HTTP 200 an. Ein Kunde kann sich damit jede global aktive Zahlart zuweisen, auch solche, die der Betreiber für diesen Channel bewusst ausgeschlossen hat.

Technische Einordnung

Die drei Lücken sind unterschiedliche Bug-Klassen, aber sie erzählen dieselbe Geschichte: eine Prüfung, die an einer zweiten Eingangstür fehlt, obwohl sie an der ersten vorhanden ist. Das ist das wiederkehrende Muster bei gewachsenen API-Oberflächen — der Checkout-Pfad ist gehärtet, der parallele Account- oder LiveComponent-Pfad zum selben Objekt ist es nicht.

Beim Channel-Bypass (GHSA-6955) ist das wörtlich der Fall: Der Checkout-Endpoint validiert die Zahlart gegen den Channel, der Account-Endpoint nicht. Zwei Wege zum selben Zustand (Zahlart einer Order setzen), nur einer trägt die Regel. CWE-863, Incorrect Authorization. Der Schaden ist begrenzt (ein Kunde umgeht eine Geschäftsregel, keine fremden Daten), aber für Betreiber mit channel-spezifischen Zahlarten-Verträgen ist es ein echtes Compliance- und Abrechnungsthema.

Beim Payment-Request-IDOR (GHSA-mr9r) fehlt die Eigentümer-Prüfung komplett: Der Hash aus der URL ist der einzige Schlüssel, eine Bindung an den authentifizierten Kunden oder die Order gibt es nicht (CWE-639). Der Hash ist eine UUID und muss out-of-band beschafft werden (Logs, geteilte Links, Referrer-Header), aber sobald er bekannt ist, braucht es kein weiteres Credential. Die PUT-Variante hebt das über reine Informationspreisgabe hinaus: Wer target_path/after_path umbiegt, kann den Käufer nach der Zahlung auf eine kontrollierte Seite leiten — eine klassische Open-Redirect-/Phishing-Brücke direkt im Bezahl-Flow.

Die Cart-Race (GHSA-5597) ist die interessanteste, weil sie keine Authentifizierungs-, sondern eine Workflow-Lücke ist (CWE-841, Improper Enforcement of Behavioral Workflow, plus CWE-672, Operation on a Resource after Expiration). Das LiveComponent geht implizit davon aus, dass eine im Browser offene Order noch im Warenkorb-Zustand ist. Diese Annahme bricht, sobald die Order parallel abgeschlossen wird. Der Fix im Release ist genau die fehlende Zustandsprüfung: hydrateResource() gibt für eine Order im Zustand STATE_COMPLETED einen frischen, leeren Warenkorb zurück, statt die abgeschlossene Order zu mutieren. Strukturell ist das die gleiche Lehre wie bei vielen Race-Conditions: clientseitig gehaltener Zustand ist eine Annahme, kein Fakt, und serverseitige Aktionen müssen den aktuellen Zustand neu prüfen.

Wer ist betroffen

Die schnellste Triage ist der Versionsstand (composer show sylius/sylius). Da alle drei Lücken im Standard-Shop- und API-Pfad sitzen, ist praktisch jeder Standard-Sylius-Shop in den betroffenen Versionsbereichen betroffen; die Frage ist nicht „ob“, sondern „wie schnell“.

Auswirkungen und Sofortmaßnahmen

Die Auswirkungen reichen von Datenverlust an bezahlten Bestellungen (Cart-Race) über Preisgabe fremder Bestelldaten inklusive Kunden-E-Mail und Adressen (Payment-Request-IDOR) bis zur Umgehung einer Geschäftsregel bei der Zahlart (Channel-Bypass). Die IDOR-Datenpreisgabe ist datenschutzrelevant: personenbezogene Bestelldaten ohne Eigentümer-Prüfung sind ein DSGVO-Art.-32-Thema, und der umbiegbare Post-Payment-Redirect ist ein Phishing-Vektor direkt am Bezahl-Flow. Für meldepflichtige Betreiber ist die Verfügbarkeits-/Integritätskomponente der Cart-Race zusätzlich ein NIS-2-Aspekt (Art. 21).

Operational Decision Block

• Sofort handeln, wenn: Ihr Sylius-Shop in einem betroffenen Versionsbereich läuft und die Shop-API öffentlich erreichbar ist (IDOR ohne Auth-Credential, nur Hash nötig).
• Im Wartungsfenster, wenn: die Shop-API nicht öffentlich exponiert ist und Sie das LiveComponent-Frontend nutzen — der Patch bleibt Pflicht, der akute Hebel ist kleiner.
• Kurz gegenprüfen, wenn: Sie ein stark angepasstes Frontend ohne Standard-Cart-LiveComponent und ohne die betroffenen API-Endpoints fahren — Versionsstand trotzdem heben.

In dieser Reihenfolge. Erstens, Versionsstand feststellen (composer show sylius/sylius). Zweitens, upgraden: composer update sylius/sylius auf 2.0.18 / 2.1.15 / 2.2.6 (je nach Minor-Linie), anschließend bin/console cache:clear. Drittens, falls ein sofortiges Upgrade nicht möglich ist, die Workarounds aus den Advisories anwenden: GHSA-5597 über einen Override des sylius_shop.twig.component.cart.form-Service mit einer Zustandsprüfung in hydrateResource(); GHSA-6955 über einen Decorator von PaymentMethodChangerInterface, der die Zahlart gegen den Channel prüft; GHSA-mr9r über eine API-Platform-Query-Extension plus State-Provider-Decorator plus Command-Bus-Middleware, die Ownership erzwingen. Viertens, nach dem Upgrade verifizieren, dass die channelfremde Zahlart über den Account-Endpoint jetzt 422 liefert und der Payment-Request-Endpoint für fremde Hashes 404 zurückgibt.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Detection / Prüfung

Lead. Die primäre Frage ist der Versionsstand; eine nachträgliche Ausnutzungs-Erkennung ist schwer, weil die Zugriffe wie reguläre API-Calls aussehen. Der Fokus liegt auf Versions-Triage und gezielter Log-Sichtung der betroffenen Endpoints.

Prüf-Snippets (Copy/Paste):

# 1) Installierte Sylius-Version feststellen
composer show sylius/sylius | grep -i versions

# 2) Auf die Fix-Versionen heben (je nach Minor-Linie)
composer require "sylius/sylius:^2.2.6"   # bzw. ^2.1.15 / ^2.0.18
bin/console cache:clear

# 3) Zugriffe auf die Payment-Request-Endpoints sichten (IDOR-Verdacht)
#    Viele GET/PUT auf verschiedene Hashes von einer Quelle = auffaellig
grep -E "/api/v2/shop/payment-requests/" var/log/*.log access.log 2>/dev/null

# 4) Account-Order-Payment-PATCH auf channelfremde Zahlarten pruefen
grep -E "PATCH .*/api/v2/shop/account/orders/.*/payments/" access.log 2>/dev/null

Was auffällig ist: eine Quelle, die viele Payment-Request-Hashes nacheinander abfragt (IDOR-Enumeration), PUT-Requests auf Payment-Requests, die target_path/after_path auf externe Domains setzen, sowie erfolgreiche PATCH-Zahlart-Änderungen über den Account-Endpoint auf Zahlarten, die im jeweiligen Channel nicht angeboten werden. Für die Cart-Race ist das Warnsignal eher in den Daten: abgeschlossene Bestellungen, die nach ihrer Fertigstellung noch Mutations- oder Lösch-Ereignisse zeigen.

Betreiberempfehlung

Mittelstand

Für die meisten Sylius-Shops ist das ein gewöhnliches Minor-Update innerhalb der eigenen 2.x-Linie: composer update sylius/sylius, Cache leeren, deployen, kurz testen. Sylius pflegt 2.0, 2.1 und 2.2 parallel, das Upgrade bleibt also in der vertrauten Linie ohne Breaking Changes. Wer einen Wartungsvertrag hat, lässt den Patch im regulären Sicherheits-Fenster einspielen; wer die Shop-API öffentlich exponiert, zieht ihn vor.

Shop-Betrieb & Anpassungen

Wer stark angepasste LiveComponents oder eigene API-Resources gebaut hat, prüft nach dem Upgrade, ob die eigenen Erweiterungen die neuen Zustands- und Ownership-Prüfungen erben oder umgehen. Besonders bei überschriebenem Cart-FormComponent gilt: die neue STATE_COMPLETED-Prüfung in hydrateResource() muss in der eigenen Variante ankommen, sonst bleibt die Race-Condition offen.

Container / Deployment

Bei containerisierten Shops gehört der Versionssprung ins Image (Composer-Update im Build), nicht in den laufenden Container; danach neu ausrollen. Der composer.lock ist die Quelle der Wahrheit — nach dem Upgrade verifizieren, dass die gepinnte Version tatsächlich 2.0.18 / 2.1.15 / 2.2.6 oder höher ist.

Fazit

Das Sylius-Release vom 2. Juni 2026 ist kein Feueralarm, aber drei Access-Control- und Workflow-Defekte direkt am Bezahl-Pfad sind nichts, was man liegen lässt. Die nüchterne Einordnung: Moderate, keine CVEs, keine bekannte aktive Ausnutzung, kein öffentlicher PoC, aber der höchste der drei (CVSS 6.5) führt zu irreversiblem Verlust bezahlter Bestelldaten, und der IDOR gibt personenbezogene Daten ohne jedes Credential preis, sobald ein Hash bekannt ist. Die Maßnahme ist erfreulich einfach: ein Minor-Update innerhalb der eigenen 2.x-Linie auf 2.0.18 / 2.1.15 / 2.2.6, Cache leeren, fertig; wer nicht sofort kann, hat für jede Lücke einen dokumentierten Override. Die wiederkehrende Lehre für eigene Shop-Anpassungen bleibt: dieselbe Prüfung gehört an jede Tür zum selben Objekt — den Checkout-Pfad zu härten und den Account- oder LiveComponent-Pfad zu vergessen, ist genau die Lücke, die hier dreimal aufgetreten ist.

Quellen

• Sylius Advisory GHSA-5597-7rmh-97q5 — Cart FormComponent allows modification or deletion of an already-completed order (CVSS 6.5, CWE-672/841, 02.06.2026)
• Sylius Advisory GHSA-mr9r-h354-966r — IDOR on Shop Payment Request endpoints in API (CWE-639, 02.06.2026)
• Sylius Advisory GHSA-6955-hrm5-c4qp — Channel-based payment method restriction bypass (CVSS 4.3, CWE-863, 02.06.2026)
• Sylius/Sylius — Security Advisories (Übersicht und Fix-Versionen 2.0.18 / 2.1.15 / 2.2.6)