Jexactyl EUVD-2026-95982

Requires an instance where the billing module is explicitly enabled AND a Stripe secret key is configured (config modules.billing.keys.secret) - both non-default deployment prerequisites. The attacker must hold a valid authenticated client account (PR:L) and an order referencing a server. Exploitation then needs only a Stripe Checkout Session whose payment_status is 'paid' with a lower amount_total or a different currency than the order; the pre-4.0.5 code trusts 'paid' without comparing amount_total or currency to the order total and configured billing currency. Limiting factors: requires authentication, requires the optional billing+Stripe configuration to be active, and only affects versions prior to 4.0.5.

This is a genuine but bounded business-logic/payment-integrity flaw rather than a critical infrastructure risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L, 7.1 High) is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated client (PR:L) and producing an integrity impact (VI:H) with no confidentiality loss (VC:N) - correctly contradicting the 'Information Disclosure' tag, since no data is exposed. No EPSS score, KEV listing, or public exploit is present in the provided data, so there is no public exploit identified at time of analysis and no confirmed active exploitation; the realistic threat is targeted financial fraud by existing authenticated customers against hosting operators, not mass/automated exploitation. Priority should be scoped to operators who actually run the billing module with a live Stripe secret key - for them this is a direct revenue-loss and provisioning-abuse issue and the fix (v4.0.5) should be applied, but for the broad install base that does not enable billing it is not a pressing concern. EPSS and KEV data are simply absent (not an error), so probability-of-exploitation cannot be quantified from the inputs.

An authenticated customer on a Jexactyl instance with the billing module enabled and Stripe configured initiates a real order, then completes a Stripe Checkout Session for a deliberately low amount or a cheap currency (e.g. 100 JPY instead of 100 USD). They POST the 'paid' session to /api/client/billing/stripe/process, and because the server never compares amount_total or currency against the order, the server is provisioned, renewed, upgraded, or unsuspended for a fraction of the real price. No public exploit code was identified in the provided data, but the mechanism is confirmed by the fix commit and its integration tests.