VYPR
Low severity3.1NVD Advisory· Published Jun 7, 2026

CVE-2026-11465

CVE-2026-11465

Description

A race condition in the redemption code top-up endpoint allows multiple users to redeem a single code concurrently, leading to unlimited balance amplification.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A race condition in the redemption code top-up endpoint allows multiple users to redeem a single code concurrently, leading to unlimited balance amplification.

Vulnerability

A race condition vulnerability exists in the Redeem function within the model/redemption.go file of the songquanpeng one-api component, specifically affecting versions up to v0.6.11-preview.7. This flaw is present only when using a MySQL backend; SQLite is not affected. The issue stems from an incorrect implementation of database transaction locking, where the FOR UPDATE clause is silently omitted from the generated SQL query by the GORM v2 API, preventing proper row locking.

Exploitation

An attacker can exploit this vulnerability by sending concurrent requests to the redemption code top-up endpoint (POST /api/user/topup) from multiple user accounts. Since the intended row lock is not acquired due to the GORM v2 API misconfiguration, multiple transactions can simultaneously read an unused redemption code, allowing each to successfully redeem it and grant a balance increase. This requires network access to the affected API endpoint.

Impact

Successful exploitation of this vulnerability allows an attacker to achieve unlimited balance amplification by redeeming a single one-time redemption code multiple times concurrently across different user accounts. This effectively allows for unauthorized credit to be added to user balances, impacting the integrity of the system's financial or quota management.

Mitigation

A pull request to fix this race condition by correctly implementing the row locking mechanism has been submitted [3]. The affected versions are from v0.1.6-alpha up to v0.6.11-preview.7 [2]. As of the available references, a patched version has not yet been released, and no specific workarounds are detailed.

AI Insight generated on Jun 7, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Songquanpeng/One APIreferences2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)range: <=0.6.11-preview.7

Patches

1
f0e177490388

Merge af3731797d3f14bb6fd241449387a09b8537a674 into 8df4a2670b98266bd287c698243fff327d9748cf

https://github.com/songquanpeng/one-apisec-reexMay 19, 2026via nvd-ref
1 file changed · +2 1
  • model/redemption.go+2 1 modified
    @@ -6,6 +6,7 @@ import (
     	"fmt"
     
     	"gorm.io/gorm"
    +	"gorm.io/gorm/clause"
     
     	"github.com/songquanpeng/one-api/common"
     	"github.com/songquanpeng/one-api/common/helper"
    @@ -66,7 +67,7 @@ func Redeem(ctx context.Context, key string, userId int) (quota int64, err error
     	}
     
     	err = DB.Transaction(func(tx *gorm.DB) error {
    -		err := tx.Set("gorm:query_option", "FOR UPDATE").Where(keyCol+" = ?", key).First(redemption).Error
    +		err := tx.Clauses(clause.Locking{Strength: "UPDATE"}).Where(keyCol+" = ?", key).First(redemption).Error
     		if err != nil {
     			return errors.New("无效的兑换码")
     		}
    

Vulnerability mechanics

Root cause

"The GORM v2 API `Set("gorm:query_option", "FOR UPDATE")` does not generate a `FOR UPDATE` clause, omitting row locking."

Attack vector

An attacker can exploit this vulnerability by sending concurrent requests to the Redemption Code Top-Up Endpoint. This requires at least two regular user accounts and one valid redemption code. The attack may be launched remotely and requires a high level of complexity, making exploitation difficult [ref_id=1]. The vulnerability affects MySQL databases only [ref_id=1].

Affected code

The vulnerability resides in the `Redeem` function within the file `model/redemption.go`. Specifically, the issue stems from the incorrect implementation of row locking using GORM v2's `Set("gorm:query_option", "FOR UPDATE")` which fails to acquire the necessary lock [ref_id=1].

What the fix does

The patch replaces `tx.Set("gorm:query_option", "FOR UPDATE")` with `tx.Clauses(clause.Locking{Strength: "UPDATE"})` [patch_id=5161670]. This change utilizes the recommended GORM v2 syntax for row-level locking, ensuring that the `FOR UPDATE` clause is correctly generated and applied to the SQL query. This prevents concurrent transactions from simultaneously accessing and redeeming the same redemption code, thus mitigating the race condition.

Preconditions

  • configThe affected backend must be MySQL [ref_id=1].
  • authRequires at least two regular user accounts [ref_id=1].
  • inputRequires one valid redemption code [ref_id=1].

Reproduction

1. Create a one-time redemption code. 2. Simultaneously send requests from two different user accounts to redeem the same code. 3. Observe that both accounts successfully redeem the code and receive the full quota, indicating a race condition and unlimited balance amplification [ref_id=1].

Generated on Jun 7, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.