CVE-2026-68500 in Mollie Plugin
Summary
by MITRE • 07/30/2026
Sylius Mollie Plugin provides Mollie payment integration for Sylius applications. Prior to 2.2.8, 3.2.4, and 3.3.1, Sylius Mollie Plugin's POST /{_locale}/update-payment payment webhook accepts attacker-controlled id and orderId parameters but does not verify that the Mollie payment belongs to the referenced Sylius order, allowing an unauthenticated attacker with any valid paid Mollie payment ID to mark a victim order as paid without transferring funds for that order. This issue is fixed in 2.2.8, 3.2.4, and 3.3.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/30/2026
The Sylius Mollie Plugin vulnerability represents a critical authorization bypass flaw that undermines the integrity of payment processing within e-commerce applications. This weakness exists in versions prior to 2.2.8, 3.2.4, and 3.3.1 where the plugin's webhook endpoint at POST /{_locale}/update-payment fails to validate the relationship between Mollie payment identifiers and corresponding Sylius orders. The vulnerability stems from insufficient input validation and lacks proper authentication mechanisms to verify that a payment belongs to the specific order being updated, creating an exploitable condition where malicious actors can manipulate payment states.
The technical implementation flaw allows attackers to submit arbitrary id and orderId parameters through the webhook endpoint without proper verification of ownership or authorization. This represents a classic case of insufficient validation of user-provided data, which aligns with CWE-284 access control vulnerabilities. The attack vector involves an unauthenticated attacker who can leverage any valid paid Mollie payment ID to manipulate the payment status of victim orders within the Sylius application. The vulnerability does not require authentication or authorization credentials from the legitimate user, making it particularly dangerous as it can be exploited by anyone with knowledge of valid payment identifiers.
Operationally, this vulnerability creates significant financial risk for merchants using the affected plugin versions. An attacker can potentially mark any order as paid without transferring actual funds, leading to revenue loss and potential inventory discrepancies. The flaw enables fraudulent activities where attackers might exploit this to claim payment for orders they never intended to fulfill, creating a scenario where legitimate customers could be denied service while fraudulent transactions are marked as complete. This type of vulnerability directly impacts the trust model between merchants and customers in e-commerce environments.
The mitigation strategy requires immediate deployment of patched versions 2.2.8, 3.2.4, and 3.3.1 which implement proper verification mechanisms to ensure that Mollie payments are validated against their corresponding Sylius orders before updating payment status. Organizations should also conduct comprehensive security assessments of their payment integrations, implement proper input sanitization for all webhook endpoints, and establish robust authentication checks for sensitive operations. This vulnerability demonstrates the importance of implementing proper authorization controls at every layer of payment processing systems, aligning with ATT&CK technique T1548.003 for privilege escalation through unauthorized access to payment information.
Security practitioners should also consider implementing additional monitoring for webhook activity, establishing rate limiting mechanisms to prevent abuse, and ensuring that all third-party payment integrations undergo thorough security review processes before deployment. The fix addresses the core issue by enforcing proper correlation between Mollie payment identifiers and Sylius order records, preventing unauthorized state changes through the webhook interface. Organizations relying on this plugin must verify their current versions are patched and consider implementing additional security controls to protect against similar vulnerabilities in other payment processing components. This vulnerability highlights the critical need for validating all external inputs and maintaining proper separation of concerns between payment processing systems and order management interfaces.