Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII

QFinch assessment

Two unauthenticated Mollie shop endpoints look up orders by a sequential integer `orderId` with no ownership or session check. Chained, they expose customer PII.

Potential impact

Two unauthenticated Mollie shop endpoints look up orders by a sequential integer orderId with no ownership or session check. Chained, they expose customer PII. GET /{locale}/thank-you (PageRedirectController::thankYouAction, route syliusmollieshopthankyoupageredirect) loads the order with findOneBy(['id' => $orderId]) and returns a 302 whose Location header carries that order's tokenValue. Any orderId thus yields that order's token. A non-existent id dereferences null and returns a 500. The handler also writes the raw orderId into the session. GET /{locale}/get-code (QrCodeAction::fetchQrCodeFromOrder, route syliusmollieshopgetqrcode) runs the same lookup and returns the order's QR code and id as JSON, ignoring the session cart; this is where the front-end got the integer id. A bad id 500s here too. That tokenValue is the order's only access control. Passed to the Sylius core page GET /{locale}/register-after-checkout/{tokenValue} it returns a form pre-filled with the customer's first name, last name and email. The full attack: enumerate orderId, read the token from the redirect, read the PII, at roughly a 1-in-71 hit rate for guest orders. register-after-checkout is Sylius core, not the plugin, and trusts the token by design, so the leak is what must be fixed. None of the plugin endpoints require a login, session or CSRF token.