What is the CVSS score of CVE-2026-55219?

CVE-2026-55219 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2026-55219?

Yes, a patch is available for CVE-2026-55219. Update the affected software to the latest version immediately.

Paymenter CVE-2026-55219

EUVD-2026-46097 MEDIUM

Race Condition (CWE-362)

2026-06-30 https://github.com/Paymenter/Paymenter

GHSA-pgcq-8grm-5rx9

PHP Authentication Bypass Race Condition

5.3

CVSS 3.1 · Vendor: https://github.com/Paymenter/Paymenter

Severity by source

Vendor (https://github.com/Paymenter/Paymenter) PRIMARY

5.3 MEDIUM

AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

vuln.today AI

5.3 MEDIUM

Authentication required (PR:L) and concurrent timing dependency (AC:H); only financial integrity is impacted with no confidentiality or availability effect.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/Paymenter/Paymenter).

CVSS VectorVendor: https://github.com/Paymenter/Paymenter

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 30, 2026 - 19:51 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Credit double-spend via race condition in Paymenter allows any authenticated user with a non-zero credit balance to settle multiple invoices for the cost of one. The root cause is that lockForUpdate() in app/Livewire/Invoices/Show.php is called outside a database transaction, rendering the pessimistic lock a no-op in MySQL/MariaDB and leaving the read-check-deduct sequence unprotected against concurrent execution. Successful exploitation results in direct financial or resource loss to the platform operator as ExtensionHelper::addPayment() provisions services or digital goods for each winning request. No public exploit has been identified at time of analysis.

Technical ContextAI

Paymenter is an open-source PHP billing and service panel (Composer package paymenter/paymenter) built on Laravel. The vulnerable code in app/Livewire/Invoices/Show.php attempts to use Laravel's lockForUpdate() - which generates a SELECT ... FOR UPDATE SQL statement - to serialize access to the user's credit balance row. However, in MySQL and MariaDB's InnoDB storage engine, SELECT ... FOR UPDATE only acquires and holds a row-level lock within the scope of an active transaction. Without an enclosing DB::transaction() call, the lock is issued and immediately released before the balance check and deduction execute, making the guard completely ineffective. CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) is the precise root cause class: the credit balance is a shared resource subject to a read-modify-write operation that lacks a valid synchronization primitive, exposing a classic TOCTOU window. PostgreSQL's autocommit and locking semantics differ and may not exhibit the same behavior.

RemediationAI

The correct fix is to wrap the entire credit balance check, lockForUpdate() call, deduction, and ExtensionHelper::addPayment() invocation inside an explicit Laravel database transaction using DB::transaction(), ensuring the pessimistic lock is held for the full duration of the atomic read-modify-write sequence. Operators should consult the GitHub Security Advisory GHSA-pgcq-8grm-5rx9 (https://github.com/Paymenter/Paymenter/security/advisories/GHSA-pgcq-8grm-5rx9) for the specific patched release version, as no exact fix version is confirmed in the currently available data. As a compensating control prior to patching, disabling credit-based payment processing entirely eliminates the attack surface but blocks legitimate credit use. Rate-limiting concurrent requests per authenticated user to the invoice payment endpoint (e.g., via middleware) narrows the race window and raises the bar for exploitation but does not eliminate it, and aggressive limits may throttle legitimate users. Adding a database-level CHECK constraint enforcing a non-negative credit balance provides a last-resort guard against the balance going negative but does not prevent double-provisioning if both transactions commit before either deduction is reflected.