A race condition exists in Paymenter’s credit payment logic, specifically in the file app/Livewire/Invoices/Show.php. The code attempts a pessimistic row lock with lockForUpdate() but performs it outside an active database transaction. Because MySQL and MariaDB require a transaction to enforce row‑level locks, the guard is ineffective, allowing simultaneous payment requests to read the same credit balance. Each request separately verifies sufficient funds and processes the payment, enabling the same credit to be applied twice and provisioning services or goods. The result is a direct financial or resource loss to the platform owner.

All releases of the Paymenter webshop solution older than 1.5.5 are vulnerable. Administrators running these versions are susceptible if they allow concurrent credit payments against the same balance.

The CVSS score of 5.3 indicates moderate severity, but the potential for monetary loss is significant. EPSS is less than 1% and the flaw is not listed in CISA KEV, suggesting that widespread exploitation has not yet been observed. The likely attack vector is a web‑based exploit: an attacker orchestrates the delivery of two or more nearly simultaneous HTTP requests to the credit payment endpoint, taking advantage of the timing gap to double‑spend. Based on the description, it is inferred that concurrency control via proper transactional boundaries or queuing is required to mitigate the risk.