Paymenter has race condition in payWithCredit() that enables credit double-spend
Summary
The credit payment implementation in app/Livewire/Invoices/Show.php executes a pessimistic row lock (lockForUpdate()) outside of an active database transaction. Because MySQL/MariaDB requires an enclosing transaction to enforce row-level locks, the guard is ineffective. Concurrent payment requests can exploit this race condition to read the same credit balance simultaneously, allowing users to pay multiple invoices using the same credit balance.
Technical Details
The issue occurs because the application attempts to lock the user's credit balance row in the database (lockForUpdate()) without opening a database transaction. In database systems like MySQL, a row lock only works inside a formal transaction; without one, the lock is completely ignored.
Because there is no active lock, two payment requests sent at the exact same millisecond can look at the database at the same time. Both requests see the original credit balance, decide it is sufficient, and approve the payment.
Impact
This race condition allows any authenticated user with a valid credit balance to bypass balance restrictions and settle multiple pending invoices simultaneously for the cost of a single invoice.
Because the payment processes successfully through ExtensionHelper::addPayment(), the application provisions the corresponding services or digital goods, resulting in direct financial or resource loss to the platform.
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Composer package | paymenter/paymenter | < 1.5.5 | 1.5.5 |
References
- CVSS vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N- Weakness (CWE)
CWE-362- Platform
- Composer
- Package
paymenter/paymenter- Disclosed
- 30.06.2026
- Updated
- 11.10.2026 10:22
Sources and licenses
OSV / GitHub Advisory Database - GHSA-pgcq-8grm-5rx9 - CC BY 4.0
Vulnerability history: paymenter/paymenter
All published vulnerabilities of this package (Composer package), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 7
- First → latest
- 06.2026 09.2026
- Without a fix
- 0
- Exploited in attacks
- 0
Severity breakdown
- Critical 1
- High 1
- Medium 5
Disclosures per year
- 2026: 7
-
Paymenter has race condition in payWithCredit() that enables credit double-spend this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.