LatePoint EUVD-2026-42227

Exploitation requires the site to have LatePoint (≤5.4.0) configured with the Stripe Connect payment processor enabled for bookings - that specific payment integration is the required feature. The attacker must possess a valid, previously 'succeeded' Stripe PaymentIntent token to replay (obtainable by making any legitimate Stripe payment themselves). Per the CVSS vector (AV:N/AC:L/PR:N/UI:N) no authentication and no victim interaction are needed, and the booking checkout endpoint is remotely reachable. The primary limiting factor is configuration: sites that do not use Stripe Connect (e.g., using another gateway or no online payments) are not exploitable via this path.

The CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), reflecting a network-reachable, low-complexity, unauthenticated integrity-only impact - consistent with the description of an unauthenticated attacker manipulating payment amounts. There is no confidentiality or availability impact; the harm is financial/business-logic integrity (revenue loss and fraudulent bookings), not data theft or outage. No EPSS score was provided, so exploitation-probability cannot be quantified from this data. The vulnerability is not listed in CISA KEV and no POC or exploit code is referenced, so there is no evidence of active exploitation - the risk is currently 'high-CVSS with a straightforward exploitation path but no confirmed in-the-wild activity.' No SSVC decision data was supplied. Overall this is a genuine priority for any site actually taking Stripe payments through LatePoint, because the exploit primitive (replaying a valid PaymentIntent token) is simple and requires no authentication, even though CISA/EPSS signals are absent.

An attacker browses to a WordPress site running LatePoint with Stripe Connect, obtains or reuses a PaymentIntent ID that previously reached 'succeeded' status (for example from a small legitimate payment they made), and submits it during a new booking checkout. Because the plugin validates the client-supplied token instead of a server-created PaymentIntent bound to the order amount, the booking is confirmed while the attacker pays an arbitrary (e.g., trivial or zero-effective) amount. No authentication and no user interaction from a victim are required; no public POC is currently referenced.