CVE-2026-115937 in commerce-mollie
Summary
by MITRE • 10/24/2026
The Mollie webhook endpoint accepts two independent, attacker-controlled parameters and never verifies that they belong together:
* commerceTransactionHash — selects which Craft Commerce transaction is completed * id — selects which Mollie payment is queried for its status
An unauthenticated attacker holding any paid Mollie payment ID from the merchant’s account can pair it with any transaction hash.
Commerce queries Mollie, sees status: paid, and marks the target transaction successful for that transaction’s full amount, regardless of how much was actually paid.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability described constitutes a critical business logic flaw within the integration between Craft Commerce and the Mollie payment gateway, specifically affecting the webhook endpoint responsible for processing asynchronous payment notifications. This issue arises from a fundamental failure in input validation and state verification, where the system accepts two independent parameters provided by an attacker without verifying their logical consistency or ownership relationship. The first parameter, commerceTransactionHash, identifies the internal transaction record within the merchant’s e-commerce platform that requires status updates. The second parameter, id, refers to the external payment identifier issued by Mollie for a specific financial instrument. Under normal operational conditions, these two identifiers must correspond to each other; however, the application logic fails to enforce this constraint, allowing an unauthenticated actor to decouple them arbitrarily.
From a technical perspective, the core deficiency lies in the absence of cross-referencing validation during the webhook processing routine. When the endpoint receives a request containing both parameters, it proceeds to query the Mollie API using the provided id to retrieve the current payment status. If the response indicates that the status is paid, the system immediately marks the transaction identified by commerceTransactionHash as successful and completes it for its full configured amount. This process bypasses any mechanism that would verify whether the external payment ID actually belongs to the internal transaction hash in question. Consequently, an attacker who possesses knowledge of a valid Mollie payment identifier from the merchant’s account can pair this identifier with any arbitrary commerceTransactionHash they choose. The system blindly trusts the status returned by the third-party provider without ensuring that the financial event corresponds to the specific order being updated.
The operational impact of this vulnerability is severe, primarily manifesting as a direct financial loss through unauthorized credit or free goods delivery. An attacker can exploit this flaw to mark any pending transaction in the merchant’s system as completed and paid for its full value, despite having no actual connection to that specific payment event. For instance, if an attacker identifies a high-value order with hash X and pairs it with the ID of a low-value or already settled payment from another customer, the e-commerce platform will release goods or services associated with transaction X without receiving corresponding funds for that specific item. This effectively allows attackers to obtain merchandise or digital products for free by manipulating the state transition logic based on unrelated financial data. The severity is compounded by the fact that this exploitation requires no authentication, making it accessible to any external actor who can observe or guess valid identifiers within the system’s ecosystem.
This vulnerability aligns with CWE-345, Insufficient Verification of Data Authenticity, as the application fails to verify that the received data corresponds to its intended context before acting upon it. Furthermore, it relates closely to CWE-829, Inclusion of Functionality from Untrusted Control Sphere, because the system relies on external input (the Mollie API response) without validating the integrity of the linkage between internal and external entities. From an offensive security perspective, this behavior is consistent with ATT&CK technique T1496, Resource Hijacking, where resources are consumed or manipulated through deceptive means, although in a business context it more accurately reflects manipulation of financial workflows akin to logic flaws often seen in CWE-840, Incorrect Comparison. The lack of idempotency checks and transaction binding allows for race conditions or simple replay attacks that distort the accounting records.
To mitigate this vulnerability, immediate remediation steps must focus on enforcing strict referential integrity between internal transactions and external payment identifiers. The webhook endpoint should be modified to validate that the commerceTransactionHash is explicitly linked to the provided Mollie id before processing any status updates. This can be achieved by storing a reference of the external payment ID within the internal transaction record at checkout initiation, ensuring that only webhooks matching this stored identifier are processed for that specific order. Additionally, implementing strict input validation and sanitization routines will help prevent injection attacks that might attempt to manipulate these parameters further. It is also advisable to implement idempotency checks to ensure that duplicate webhook notifications do not trigger multiple state changes or financial adjustments. Finally, merchants should review their logging mechanisms to detect anomalies in payment-to-transaction mappings and consider adding manual reconciliation processes for high-value transactions until the code fix is deployed.