Commerce Alphabank Redirect EUVD-2025-18126

The CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates critical risk factors: (1) Network-accessible attack vector with no special privileges required; (2) Low attack complexity requiring only standard techniques; (3) User interaction requirement slightly reduces immediate exploitability but does not eliminate risk in real-world scenarios where users interact with payment redirects; (4) High impact across all three security pillars (confidentiality, integrity, availability). The authorization bypass nature combined with payment processing context elevates real-world risk substantially. Absence of KEV designation and public POC suggests this may be relatively recent or low visibility, but this does not diminish the inherent risk—authorization flaws in payment gateways are consistently exploited. The UI:R requirement moderately reduces the EPSS exploitation probability compared to a fully unauthenticated attack, but typical payment workflows involve user clicks on redirect links, making this practically exploitable. This is a legitimate high-priority vulnerability, not a false positive, given the payment processing context and authorization bypass nature.

An attacker crafts a malicious link or POST request targeting the Drupal Commerce Alphabank Redirect functionality. Through improper authorization checks, the attacker bypasses intended permission validation and gains the ability to: (1) redirect legitimate payment flows to attacker-controlled endpoints, (2) capture or modify payment data in transit, or (3) disrupt payment processing availability. The attack begins with social engineering (phishing email, compromised ad, or site injection) to trick a legitimate user into clicking the malicious link or submitting a form. Once the user interacts with the redirected payment flow, the lack of proper authorization checks allows the attacker to execute unauthorized payment-related actions. Example: An attacker crafts a URL with manipulated parameters that bypasses role checks, allowing them to initiate refunds, modify payment destinations, or capture transaction metadata without proper authentication/authorization. The UI:R requirement means the vulnerability requires victim interaction but is easily triggered in a payment workflow context where users naturally click payment links.