CVE-2026-55219: 
PHP vulnerability analysis and mitigation

CVE-2026-55219 is a race condition vulnerability in Paymenter's credit payment implementation that allows authenticated users to double-spend credits by paying multiple invoices with the same credit balance. The flaw exists in app/Livewire/Invoices/Show.php within the payWithCredit() function, affecting Paymenter versions up to and including 1.5.4. It was published on June 30, 2026, with a patch released in version 1.5.5. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is classified as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization). The application calls lockForUpdate() — a pessimistic row lock — on the user's credit balance row outside of an active database transaction. In MySQL/MariaDB, row-level locks are only enforced within an explicit transaction; without one, the lock is silently ignored. As a result, two or more concurrent HTTP requests can simultaneously read the same credit balance, each independently determine it is sufficient, and both proceed to approve payment via ExtensionHelper::addPayment() (GitHub Advisory, Paymenter Advisory).

Successful exploitation allows any authenticated user with a valid credit balance to bypass balance restrictions and settle multiple pending invoices simultaneously at the cost of only a single invoice. Because payments are processed successfully through ExtensionHelper::addPayment(), the platform provisions the corresponding services or digital goods for each approved payment, resulting in direct financial loss or unauthorized resource acquisition for the platform operator. There is no confidentiality or availability impact; the integrity impact is high due to unauthorized manipulation of financial transaction records (GitHub Advisory).

1. Authenticate: Log in to a Paymenter instance (version ≤ 1.5.4) with a valid user account that holds a credit balance sufficient to pay at least one invoice.
2. Identify target invoices: Locate two or more pending invoices whose individual costs are each within the available credit balance.
3. Craft concurrent requests: Prepare multiple simultaneous HTTP POST requests targeting the payWithCredit() endpoint in app/Livewire/Invoices/Show.php, each referencing a different invoice ID.
4. Race the requests: Use a tool such as curl with parallel execution, Python's asyncio/aiohttp, or a custom script to send all requests at the same millisecond, exploiting the window before any balance deduction is committed.
5. Collect provisioned services: Because both requests read the same pre-deduction balance and both pass the sufficiency check, ExtensionHelper::addPayment() is called for each, provisioning services or digital goods for all invoices while only deducting the balance once (GitHub Advisory).

• Logs: Multiple successful payment log entries for different invoices within the same millisecond or sub-second window for the same user account; repeated calls to ExtensionHelper::addPayment() in application logs without corresponding balance deductions.
• Database: Credit balance records showing a single deduction despite multiple invoices being marked as paid; invoice status tables reflecting multiple invoices paid simultaneously by the same user.
• Application Behavior: Unexpected provisioning of multiple services or digital goods for a user whose credit balance should only cover one item (GitHub Advisory).

Upgrade Paymenter to version 1.5.5, which contains the fix for this vulnerability. The remediation wraps the credit payment logic in a proper database transaction so that lockForUpdate() is enforced correctly by MySQL/MariaDB. No configuration-based workaround is documented; upgrading is the only recommended remediation (GitHub Advisory, Paymenter Advisory).