【中危】paymenter 安全更新（GHSA-pgcq-8grm-5rx9）

安全情报快照 · 风险级别：中危 · CVSS：5.3 · CVE-2026-55219 · GHSA-pgcq-8grm-5rx9

先看结论

paymenter存在安全风险，<= 1.5.4 受影响，建议升级至 1.5.5。

影响范围

处置建议

优先将 paymenter/paymenter 升级至 1.5.5 或更高版本；升级前请结合业务依赖完成兼容性验证。

上游技术详情（原文）

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.

来源与许可

• GitHub Advisory GHSA-pgcq-8grm-5rx9
• https://github.com/Paymenter/Paymenter/security/advisories/GHSA-pgcq-8grm-5rx9

本页自动同步 GitHub Advisory Database 的公开数据，并保留上游原文供核验；不宣称原创分析。数据许可：CC-BY-4.0。