Nexi XPay Build CVE-2026-82211

Requires a target WordPress site running the Nexi XPay Build plugin at version 7.6.2 or earlier with its payment integration active (effectively a WooCommerce store using Nexi XPay as a gateway). The exploitable surface is the plugin's payment-result handling routes, which are reachable without authentication and do not verify the payment result passed to them - so no credentials, user interaction, or non-default configuration are needed beyond having the plugin installed and processing orders. The practical LIMIT on exploitation is the narrow installed base of this specific gateway plugin; there is no platform or privilege barrier once a vulnerable site is identified.

Multiple signals converge on this being a genuine, actionable priority rather than a paper-high score. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes fully remote, unauthenticated, low-complexity exploitation with no user interaction, which matches the description's claim of unverified 'unauthenticated routes' - the vector and narrative are consistent, not conflicting. A public exploit is confirmed available (reported by WPScan), which raises real-world likelihood beyond the base score. However, note the gaps: no EPSS score and no KEV listing are provided, so exploitation is 'publicly available exploit code exists' but NOT confirmed as actively exploited - do not treat POC availability as in-the-wild activity. The 8.2 score is driven primarily by Integrity (I:H, attacker can mark arbitrary orders paid/failed or cancel them - direct financial/business-logic fraud) with only Low Confidentiality (C:L, exposure of order keys/guest buyer details) and no Availability impact. The main brake on real-world priority is product prevalence: this is a niche regional payment-gateway plugin, so widespread mass exploitation is less likely than targeted abuse of specific merchant sites running it.

An attacker enumerates a WooCommerce/WordPress store running the Nexi XPay Build plugin and sends crafted requests directly to its unauthenticated payment-result routes, which never validate the authenticity of the payment outcome. Without any credentials or user interaction, the attacker marks their own unpaid order as 'paid' to obtain goods for free (or cancels/fails other customers' orders), and separately retrieves order keys that disclose guest buyers' personal details. A public exploit for this flaw is available via WPScan, lowering the barrier to abuse.