OpenCart EUVD-2026-113823

Requires a logged-in customer account (PR:L) on an OpenCart store (through 4.1.0.4) where both the reward points extension and the Free Checkout (zero-total) payment method are enabled. The specific abuse: apply reward points, save Free Checkout as the payment method, then send zero reward points via the reward.save endpoint - the confirm handler (reward.php lines 89-94 / free_checkout.php lines 47-55) then advances the order to Free Checkout status without payment. Limiting factors: exploitation is impossible without customer authentication, the store must actually offer reward points and Free Checkout, and the abuse depends on executing the specific multi-request save/clear sequence (reflected as AC:H/AT:P); impact is confined to placing unpaid orders (merchant revenue loss), with no data exposure or service disruption.

All signals converge on a low-urgency, low-severity business-logic flaw. The VulnCheck/CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) scores just 2.3, with the only impact being VI:L (low integrity) and no confidentiality or availability impact - consistent with a payment-bypass abuse rather than system compromise. PR:L confirms an authenticated (logged-in customer) actor is required, and AC:H plus AT:P reflect that the abuse depends on a specific multi-step request sequence and a particular store configuration rather than a trivially repeatable single request. The vuln.today decision label is 'monitor', the lowest routine tier, and the issue is not in CISA KEV. No EPSS score is provided in the input, so probabilistic exploitation likelihood cannot be quoted. A public write-up (abraxaslabs) and a VulnCheck advisory describe the technique, but the input does not mark exploit code as confirmed-working. Net: this is a genuine but narrow fraud/revenue-loss issue for OpenCart merchants, not a high-priority remote-compromise vulnerability; the low CVSS and 'monitor' label are mutually consistent, and there is no conflicting signal suggesting under-rating.

A logged-in customer on an OpenCart store that offers reward points and the Free Checkout (zero-total) payment method applies reward points, saves Free Checkout, then submits zero reward points via the reward.save endpoint. The confirm handler still advances the order to Free Checkout status, so the attacker receives a full-price order placed without any payment. A public PoC reference describing this exact sequence exists, though it is not verified as working exploit code.