EUVD-2026-94196
GHSA-8fcj-x85r-h3ff
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify target order lacking stored token
-
DeliverySend crafted request to payment notification route
-
ExploitToken validation bypassed, request accepted
-
ExecutionOrder payment status forged (paid/failed)
-
ImpactFraudulent fulfillment or order disruption
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | Exploitation requires that the targeted WooCommerce order has NO stored security token - the notification route accepts the request in that state because the token comparison is effectively skipped, so the attacker must target orders in that tokenless condition. No authentication, user interaction, or special attacker privileges are needed (PR:N/UI:N), and the plugin must be installed and reachable at version through 7.6.2 with its payment notification endpoint exposed. The main limiting factor is that the order must be in the tokenless state for the bypass to apply; orders with a correctly stored token are not affected by this specific gap. |
| Impact | The provided CVSS v3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, base 7.5) describes a remotely reachable, low-complexity, unauthenticated flaw with no user interaction and a pure integrity impact - consistent with a broken-authorization business-logic bug in a payment notification handler. Publicly available exploit code exists (reported by WPScan), which raises practical risk above a theoretical high-CVSS issue, but the vulnerability is NOT in CISA KEV and no EPSS score was provided, so there is no evidence of active or widespread exploitation at time of analysis - treat POC availability and active exploitation as distinct signals. The real-world priority is tempered by product footprint: this is a specific WooCommerce/Nexi payment gateway plugin rather than ubiquitous infrastructure, so impact is concentrated among e-commerce sites running this plugin. One data conflict to flag: the input Tags include 'Information Disclosure,' but the CVSS vector shows C:N/I:H/A:N and the description is about fraudulently changing order payment state - this is an integrity/authorization fraud issue, not information disclosure. Net assessment: a genuinely exploitable, POC-backed payment-fraud flaw that should be prioritized by affected merchants, but not a mass-exploited internet-wide emergency on current evidence. |
| Exploit ScenarioDerived | An unauthenticated attacker sends a crafted request to the plugin's payment notification route for a target order that has no stored security token, and because the token check is bypassed the request is accepted. The attacker marks their own unpaid order as 'paid' to obtain goods without payment, or flips a legitimately paid order to 'failed' to disrupt the merchant. Publicly available exploit code exists, and the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms this requires only a single low-complexity remote request with no authentication or user interaction. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Unauthenticated attackers can forge payment-notification callbacks to the Nexi XPay Build WordPress plugin (through version 7.6.2) and mark arbitrary WooCommerce orders as paid - or downgrade genuinely paid orders to a failed status - because the plugin skips its security-token comparison whenever the targeted order has no stored token. The issue is remotely reachable at low complexity with no authentication and no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, base 7.5), and the impact is purely integrity-based: no confidentiality loss, but direct tampering with order and payment state on the store. Publicly available exploit code exists; however, no CISA KEV listing or other confirmation of active exploitation is present in the supplied intelligence, and exploitation is constrained to orders that happen to be in the tokenless condition.
RemediationAI
No vendor-released fix version is identified in the supplied data - the advisories and references provided document the affected range (through 7.6.2) but not a patched release - so patch status should be verified directly against the WPScan advisory (https://wpscan.com/vulnerability/66df6adb-336c-4660-9a63-5e6e550a2edb/) and the plugin vendor's changelog before assuming a fix exists; applying any newer release the vendor publishes is the preferred action. Until a confirmed patch is available, the most reliable mitigation is to deactivate the Nexi XPay Build plugin and switch checkout to a different payment method, accepting the clear trade-off that Nexi XPay payments stop working entirely. If the gateway must remain live, restrict the payment notification route at the web server or WAF so that only Nexi's published callback source addresses can reach it - this preserves legitimate notifications but breaks whenever the provider rotates or adds IP ranges and requires ongoing allowlist maintenance. A targeted code-level workaround is to hook the plugin's notification handling and reject any request whose target order has no stored token (fail closed instead of fail open), which addresses the exact precondition this CVE relies on but adds custom code that must be re-applied after each plugin update. Independently, reconcile WooCommerce order and payment statuses against the Nexi XPay merchant portal or settlement reports, and alert on orders flipped to 'paid' without a matching transaction or downgraded from paid to failed, since these are the observable effects of successful exploitation and the only way to detect tampering after the fact. Detection should not rely on authentication or user-interaction barriers, as the flaw is unauthenticated (PR:N/UI:N) and public exploit code exists.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected code is a WordPress/WooCommerce payment-gateway plugin that implements a server-to-server notification (webhook/callback) route, the standard pattern by which a payment provider such as Nexi XPay informs the shop that a transaction succeeded or failed. Because such routes are reachable by any remote client, they must authenticate each inbound message - typically by comparing a shared secret or per-order security token that was stored when the payment session was created. Here the validation logic short-circuits: when the target order has no stored token, the comparison is effectively skipped and the request is accepted, so the notification's claimed status is applied without proof of origin. This is a broken-authorization / authentication-bypass class defect (the input records no CWE assignment, though it maps conceptually to improper authentication CWE-287 or incorrect authorization CWE-863 rather than to a memory-safety or injection issue). The supplied CPE cpe:2.3:a:unknown:nexi_xpay_build:*:*:*:*:*:*:*:* indicates the vendor field is unresolved in the identifier but the component is the Nexi XPay Build plugin, with the '*' version wildcard matching all releases including the affected range through 7.6.2. The root architectural weakness is state-dependent: the guard depends on data (a stored token) whose absence flips the check into an accept, rather than failing closed - a pattern that also makes exploitation deterministic and trivially scriptable once an attacker knows an order identifier.
Know when Nexi Xpay Build gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Remote unauthenticated single request with no user interaction (AV:N/AC:L/PR:N/UI:N); impact is forged order state so I:H, with no data disclosure (C:N) or availability loss (A:N).
Primary rating from Vendor (WPScan).
CVSS VectorVendor: WPScan
DescriptionCVE.org
The Nexi XPay Build WordPress plugin through 7.6.2 does not correctly validate the security token on its payment notification route, accepting the request when the target order has no stored token, which allows unauthenticated attackers to mark arbitrary orders as paid, or to mark genuinely paid orders as failed.
Technical POC Analysis
Bug class: insufficient verification of data authenticity on an unauthenticated callback surface.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
An unauthenticated weakness in the Nexi XPay Build plugin for WordPress/WooCommerce (versions through 7.6.2) lets attackers forge payment-notification callbacks and alter whether store orders appear paid or failed, and no vendor patch is currently available. Any merchant using this plugin in its e-commerce checkout flow therefore faces direct financial-integrity risk: revenue can be falsely recognized on unpaid orders, or legitimate payments recorded as failures, degrading payment reconciliation and customer trust. Leadership should prioritize this for any online storefront running the plugin, since exploitation requires no credentials and public exploit code is already circulating.
No vendor-released patch identified at time of analysis; interim mitigations include deactivating or removing the Nexi XPay Build plugin, blocking external access to its payment-callback endpoint at the WAF or reverse proxy, adding server-side logic that rejects callback requests for orders lacking a stored security token, monitoring and reconciling order-status changes against Nexi settlement records, and requiring manual verification of payment status on high-value orders.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB