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.

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

MEDIUM

Race Condition (CWE-362)

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

GHSA-pgcq-8grm-5rx9

Authentication Bypass Race Condition PHP

5.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory 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 GitHub Advisory.

CVSS VectorGitHub Advisory

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

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

DescriptionGitHub Advisory

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. …

Unlock full vulnerability intelligence

Risk assessment & exploitation conditions
Attack chain visualization
Remediation with exact patch versions
Threat intelligence from 22 sources
Personal watchlist & email alerts

Continue with Google Continue with GitHub

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Recon

Authenticate with valid user account

Delivery

Accumulate credit balance via legitimate top-up

Exploit

Identify multiple open invoices each costing the full balance

Install

Script concurrent HTTP payment requests for all invoices

lockForUpdate() fires outside transaction and is ignored

Execute

Both balance checks pass on stale read

Impact

Services provisioned for each request at single-invoice cost

Recon

Authenticate with valid user account

Delivery

Accumulate credit balance via legitimate top-up

Exploit

Identify multiple open invoices each costing the full balance

Install

Script concurrent HTTP payment requests for all invoices

lockForUpdate() fires outside transaction and is ignored

Execute

Both balance checks pass on stale read

Impact

Services provisioned for each request at single-invoice cost

Vulnerability AssessmentAI

Exploitation	Exploitation requires a valid authenticated session (CVSS PR:L confirms this - unauthenticated attackers cannot reach the vulnerable code path). … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment	The assigned CVSS 5.3 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N) is directionally appropriate. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario	An authenticated Paymenter user with 100 credits and two open invoices each priced at 100 credits writes a short script that fires both payment POST requests simultaneously using concurrent threads or async HTTP calls. Both requests enter `app/Livewire/Invoices/Show.php`, read the balance as 100 without holding any effective lock, each conclude the balance is sufficient, and both call `ExtensionHelper::addPayment()` - provisioning two services while only one deduction (or none, depending on timing) ultimately reflects. …
Remediation	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. … Detailed patch versions, workarounds, and compensating controls in full report.