Sylius Mollie Plugin: payment webhook forgery and order ID enumeration — fixed in 2.2.9 / 3.2.5 / 3.3.2

TL;DR — 90 seconds

Affected?

sylius/mollie-plugin (the official Sylius payment plugin for Mollie) in versions 2.2.8, 3.2.4, and 3.3.1, plus earlier releases. The payment webhook controller and the checkout's QR-code and thank-you endpoints are affected.

Risk?

Two GitHub Security Advisories (GHSA-rc52-c4hv-w89p, High: payment status forgery via the webhook; GHSA-x83g-979r-f5fh, Moderate: order ID enumeration with PII exposure and DoS potential). CVE numbers are still pending as of this article.

Immediate action?

Update to sylius/mollie-plugin ≥2.2.9, ≥3.2.5, or ≥3.3.2. If you can't update right away, cover the webhook and order endpoints via controller decoration (see Mitigation).

Recommendation?

If you're still running the orphaned predecessor packages bitbag/mollie-plugin or mollie/sylius-plugin, migrate to sylius/mollie-plugin as well — those packages are no longer maintained.

Criticality?

medium (hero badge) — a real fraud risk in the payment path and PII exposure, but no confirmed active exploitation and no RCE.

What is the problem?

On July 9, 2026, the Sylius project published a security release for the official Mollie payment plugin (sylius/mollie-plugin). Two independent vulnerabilities, rooted in the same module, affect the payment and order path of Sylius shops that use Mollie as a payment provider.

The core flaw of the first advisory (GHSA-rc52-c4hv-w89p): the payment webhook controller accepts two user-controlled parameters without verifying that the referenced Mollie payment ID actually belongs to the affected order. An attacker can genuinely pay for their own low-value order, take the resulting (now-paid) Mollie payment ID, and replay it against any other order ID — marking someone else's order as paid without any actual payment.

The second advisory (GHSA-x83g-979r-f5fh) affects the shop's QR-code display and thank-you redirect endpoints: both resolve orders via a sequential, predictable ID without checking whether the requesting session is even allowed to access that order.

Who is affected?

Every Sylius shop (2.x and 3.x) that integrates Mollie as a payment method via the official plugin and runs publicly reachable checkout or webhook endpoints is affected — practically every production Mollie shop. Anyone running one of the two deprecated third-party packages (bitbag/mollie-plugin, mollie/sylius-plugin) is additionally affected by the lack of support and should plan the switch to the official package.

Impact

GHSA-rc52-c4hv-w89p enables outright payment fraud: orders get booked as paid without any money reaching the merchant — with direct financial losses and potential shipping of goods with no payment received. GHSA-x83g-979r-f5fh allows enumerating order IDs at scale, harvesting customer names and email addresses; the repeated requests against the affected endpoints also work as an unauthenticated DoS vector against checkout.

Neither flaw requires privileged access — a normal shop account (for the payment forgery: the ability to place a regular order yourself) is enough.

Mitigation / immediate steps

Note: exact controller names and routes weren't fully published in the official Sylius advisory; the steps below summarize the official recommendation and should be cross-checked against the GHSA advisories and the plugin changelog.

Operational decision block

• Act now if … you run sylius/mollie-plugin in a version below 2.2.9 (2.x), 3.2.5 (3.2.x), or 3.3.2 (3.3.x) in production.
• Check with priority if … you're still running bitbag/mollie-plugin or mollie/sylius-plugin — those packages get no fix and need to be migrated.
• Monitor only if … you're already on sylius/mollie-plugin ≥2.2.9 / ≥3.2.5 / ≥3.3.2 and don't use Mollie as a payment method.

Step 1 — update the plugin version

# check version
composer show sylius/mollie-plugin | grep versions
# update to the patched version (example for the 3.3 line)
composer require sylius/mollie-plugin:^3.3.2

Step 2 — replace deprecated third-party packages

# instead of bitbag/mollie-plugin or mollie/sylius-plugin:
composer remove bitbag/mollie-plugin
composer require sylius/mollie-plugin
# then adjust bundle registration, service prefix, template overrides, and
# namespace references per the migration guide

Step 3 — workaround if an immediate update isn't possible

// Harden the WebhookController via the decorator pattern:
// before accepting a status change, verify that the incoming Mollie payment ID
// actually matches the payment ID stored on the order
// (services.yaml: register a decorator on the existing webhook controller)

// Harden the QrCode and thank-you controllers via decorators:
// before serving the order, verify that the calling session/token
// actually owns the requested order ID

Step 4 — check for manipulation that may have already happened

# reconcile orders with status "paid" against actual Mollie transactions
# (count of paid orders vs. count of completed Mollie payments per period)

Detection / verification

Check the plugin version

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

Look for suspicious webhook calls in the logs

# reuse of the same Mollie payment ID against different order IDs
grep "mollie" access.log | grep -oE "payment_id=[a-zA-Z0-9_]+" | sort | uniq -c | sort -rn | head -20

Detect order enumeration

# sequential order ID requests from the same source in a short window
grep -E "/(qr-code|thank-you)/" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Runtime indicators

- orders with status "paid" that can't be matched to a completed Mollie transaction
- unusually many 200 responses against sequentially incrementing order IDs from the same IP
- support requests about orders marked paid that were never actually settled

Operator guidance

Act now: if you run a production Sylius shop with Mollie as a payment method, update sylius/mollie-plugin to the patched version this week — the payment forgery is a direct fraud risk with real balance-sheet impact, not a theoretical scenario.

Priority: if you're still running bitbag/mollie-plugin or mollie/sylius-plugin, plan the migration to the official package regardless of this specific issue — orphaned payment integrations are a recurring risk.

Monitor: shops without a Mollie integration, or already on the patched versions, aren't acutely affected, but should still establish reconciling paid orders against Mollie transactions as a routine check.

Conclusion

Both flaws follow a familiar pattern in payment integrations: webhook and return endpoints that trust the external payment provider more than they trust their own database. The fix is simple — a version update — but the consequence of skipping it isn't: direct financial loss and data exposure. If you process Mollie payments through Sylius, apply the patch this week, and use the move away from the deprecated third-party packages as an opportunity while you're at it.

Sources

• Sylius — MolliePlugin: Security blog post – 2.2.9, 3.2.5 and 3.3.2 (Jul 9, 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