Sifalo Pay CVE-2026-94261

Exploitation requires that the target site runs the Sifalo Pay plugin at a version below 2.5.3 with pending/unpaid orders present in the order flow. The attacker must first hold at least one valid payment transaction identifier, which they obtain by completing a genuine payment of their own through the same store - this is the concrete prerequisite stated in the description ('holding one valid transaction identifier from a payment of their own'). No authentication to the victim account is needed (PR:N) and no user interaction is required (UI:N). The limiting factors are: the plugin must be installed and active in a vulnerable version, the store must support a payment-confirmation step the attacker can invoke, and the attacker must be able to make at least one real transaction to harvest a usable identifier. Impact is bounded to integrity (orders falsely marked paid); no data disclosure or service disruption results.

This is a genuine but moderate-severity access-control flaw (CWE-639, IDOR) rather than a critical priority. The CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) correctly reflects an unauthenticated, low-complexity network attack with only limited integrity impact and no confidentiality or availability loss. Multiple signals point to limited real-world urgency: EPSS is low at 0.17% (5th percentile), and the SSVC decision framework records Exploitation as 'none' - meaning no observed active exploitation despite public POC. However, SSVC flags Automatable: yes, which is consistent with a simple repeatable HTTP request to mark orders paid, so opportunistic abuse against exposed stores is plausible. Publicly available exploit code (WPScan) raises the practical likelihood above what EPSS alone suggests, but there is no CISA KEV listing and no evidence of in-the-wild use. Net: a credible financial-fraud/business-logic risk for sites running the plugin, but not a drop-everything issue given the bounded impact (I:L only) and the absence of confirmed exploitation. The main conflicting signal to note is low EPSS/SSVC-exploitation versus public POC + automatable - treat as realistic-but-not-yet-exploited, and prioritize by whether the affected store processes real orders.

An attacker first makes a small legitimate purchase through a Sifalo Pay-enabled store to obtain one valid transaction identifier. They then replay or submit that identifier against the plugin's payment-confirmation endpoint for other users' pending orders, causing those arbitrary orders to be marked as paid without any real payment. A public exploit is available (WPScan), and because the flaw is unauthenticated (PR:N), low-complexity (AC:L), and automatable, an attacker can script this to defraud a merchant at scale.