Craft Commerce Mollie EUVD-2026-109205

Requires the Craft Commerce Mollie plugin at a vulnerable version (>= 2.1.1 and < 4.4.3) with its Mollie webhook endpoint reachable. The one concrete prerequisite is that the attacker must possess any valid, genuinely-paid Mollie payment ID belonging to the same merchant account (obtainable, for example, via a legitimate low-value purchase); this paid id is then paired with the commerceTransactionHash of any target order. No authentication is required (PR:N), no user interaction (UI:N), and default configurations are affected because the webhook never checks that the id and the transaction hash belong together. The practical limiting factor is sourcing a paid payment ID from the merchant - not a high barrier, but it is a required input.

This is a genuine priority for any merchant running the affected plugin, not a high-score-but-low-risk issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes fully remote, unauthenticated exploitation with low complexity and no attack requirements, and the single high impact is to integrity (VI:H) with no confidentiality or availability effect - consistent with CWE-345 (insufficient verification of data authenticity) and the advisory's framing as an authorization bypass / payment reuse. The vendor confirms this is a high-severity authorization-bypass fix (release 4.4.3, GHSA-3qcx-mjf6-48vj). The vuln.today decision label is 'this_week' rather than act_now/emergency. No EPSS score and no KEV status were supplied, so there is no evidence of confirmed active exploitation or a modeled exploitation probability - absence of these is not evidence of safety. A public PoC/report reference exists via Hackrate hacktivity (report 1962), but it is not verified as working exploit code. Note a data conflict worth flagging: the input tags this as 'Information Disclosure', yet the CVSS vector sets VC:N and the mechanism is unauthorized state change (marking orders paid), i.e. an integrity/authorization issue, not disclosure - the tag appears mislabeled.

An unauthenticated attacker who holds any single genuinely-paid Mollie payment ID from the merchant's account (e.g. from a small legitimate purchase) sends a webhook request to the Commerce Mollie endpoint pairing that paid id with the commerceTransactionHash of an unpaid high-value order. Commerce queries Mollie, sees status: paid, and marks the targeted transaction successful for its full amount, releasing goods or services without payment. A public PoC/report reference exists (Hackrate report 1962) but is not verified as working exploit code.