Eurobank Payment Gateway EUVD-2026-109635

No special conditions in the default state - the plugin ships with the authenticating secret empty by default, so an unauthenticated remote attacker can forge payment-confirmation requests against a default installation of the Eurobank WooCommerce Payment Gateway plugin (through 2.1.1) with no secret. Forcing an order into 'failed' status requires no secret under any configuration. The primary limiting factor is that marking an order 'paid' can be prevented if the operator has explicitly configured a non-empty confirmation secret (which would still be bypassable only if the provider-origin verification weakness also applies); the store must be internet-reachable and the attacker must reference existing/pending order identifiers. The flaw is confined to order-status manipulation - there is no stated data exfiltration or code execution.

This is a moderate-severity business-logic/authorization flaw, not a memory-corruption or RCE issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:N/I:L/A:N) is internally consistent with the description: a remote, unauthenticated attacker can reach the payment-confirmation endpoint over the network with low complexity and no user interaction, and the impact is limited to integrity (order status) with no confidentiality or availability loss - hence the 5.3 (Medium) base score. The exploitation signals are mixed-to-low: there is no CISA KEV listing and EPSS is not provided, so there is no evidence of active or widespread exploitation; a public PoC reference exists (WPScan) but it is not verified as working exploit code. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a real-but-not-urgent priority. The principal caveat is that the real-world business impact may exceed the I:L rating in merchant terms: being able to mark arbitrary pending orders as 'paid' can enable fraudulent order fulfillment (goods shipped without payment), while forcing orders to 'failed' can disrupt legitimate transactions. The 'Information Disclosure' tag is inconsistent with the vector and description - this is an integrity/authorization-bypass issue, not disclosure. CWE is N/A, so the exact weakness class (missing authenticity verification / improper authorization on a webhook) is inferred from the description rather than vendor-classified.

An attacker places or identifies a pending order on a WooCommerce store running this plugin, then sends a forged payment-confirmation (webhook/callback) request directly to the plugin's confirmation endpoint; because origin is not verified and the authenticating secret ships empty by default, the request is accepted and the order is marked 'paid', potentially triggering fulfillment without any funds being captured. Separately, an attacker can force any order into a 'failed' status with no secret at all, disrupting legitimate transactions. A public PoC reference exists (WPScan) but is not verified as working exploit code; given AV:N/AC:L/PR:N/UI:N, exploitation requires only unauthenticated network requests against a reachable store.