Paymenter CVE-2026-71537

Requires an authenticated Paymenter customer account (PR:L) with an active service that is eligible for a downgrade whose proration yields a positive credit refund (the vulnerable branch runs when $price->price <= 0 and the 'credits_on_downgrade' setting is left at its default true). Exploitation is performed by sending concurrent/parallel downgrade requests so multiple threads pass the Service::upgradable read before any credit is committed. Limiting factors: attacker must own a downgradable service, the credits-on-downgrade feature must be enabled (default), and success depends on winning a timing window (multiple simultaneous requests), though this window is easily hit in practice; affects Paymenter <= 1.5.6 only.

This is a genuine but moderate-severity business-logic flaw, not a high-impact system compromise. The vendor CVSS of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) correctly captures a network-reachable, authenticated integrity-only issue with no confidentiality or availability impact - despite the 'Information Disclosure' tag, nothing is disclosed. The single most debatable metric is AC: CWE-362 TOCTOU races generally warrant AC:H because success is timing-dependent, yet this particular race is reliably winnable by simply firing several concurrent HTTP requests, which is why the vendor chose AC:L; I assess AC:H (~5.2) while acknowledging the vendor's AC:L (~6.4-6.5) is defensible. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation is currently theoretical - there is no public exploit identified at time of analysis. Real-world priority is bounded: exploitation requires an authenticated customer account on a Paymenter instance AND an active downgradable service that yields a credit refund, and impact is financial fraud (inflated store credit) against the operator rather than takeover. Prioritize patching for any billing-facing Paymenter deployment because the fraud is direct and repeatable, but this is not a drop-everything emergency.

An authenticated customer holding an active service that is eligible for a downgrade (producing a proration credit) submits many downgrade requests in parallel. Because Service::upgradable is checked with an unlocked read and no DB::transaction/lockForUpdate spans the check and the $credit->increment('amount', abs($price)) update, each request sees 'no pending upgrade,' creates its own upgrade record, and credits the refund again - multiplying one legitimate refund into N spendable credits usable to pay future invoices or provision services. No public POC is provided, but the race is straightforward to trigger with concurrent requests.