Mar 30, 2026·6 min read·0 visits
A race condition in the WWBN AVideo YPTWallet plugin allows authenticated attackers to double-spend funds by submitting concurrent transfer requests. The lack of database-level locking during the read-check-write cycle enables the exploitation.
WWBN AVideo versions up to and including 26.0 suffer from a Time-of-Check-Time-of-Use (TOCTOU) race condition in the YPTWallet plugin's transfer logic. This vulnerability allows authenticated users to bypass balance checks via concurrent requests, enabling unauthorized financial transfers. The flaw is compounded by a secondary vulnerability that permits captcha token reuse.
WWBN AVideo is an open-source video platform that supports community interaction and content monetization. The application includes a YPTWallet plugin, which provides an internal wallet system for users to hold balances and transfer funds to other accounts. This component exposes an attack surface where authenticated users interact with financial state data.
CVE-2026-34368 identifies a Time-of-Check-Time-of-Use (TOCTOU) race condition within this wallet transfer functionality. The vulnerability resides in the transferBalance() method of the YPTWallet.php file. Due to improper synchronization, the application processes financial transactions in a non-atomic manner.
This flaw is formally classified as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization). The vulnerability affects all AVideo installations running version 26.0 and earlier. Successful exploitation allows an authenticated user to bypass balance constraints and perform unauthorized fund transfers, directly impacting the integrity of the application's financial ledger.
The fundamental issue stems from a lack of database-level concurrency controls during the balance transfer process. The transferBalance() method executes a three-step sequence: read the current balance, verify the balance is sufficient for the requested transfer, and write the updated balance to the database. These operations occur entirely within the application layer without transactional isolation.
Because the application uses a standard SELECT query to retrieve the user's balance, no row-level locks are applied to the corresponding database record. When multiple concurrent requests initiate a transfer for the same account, they independently execute the read operation before any write operation concludes. This results in each request reading the identical initial balance state.
The application then performs the mathematical check to ensure the balance exceeds the transfer amount in PHP memory. Since all concurrent threads read the same initial balance, all threads pass the validation check. The application subsequently writes the new balance to the database using separate UPDATE statements, effectively processing multiple transfers while only deducting the funds corresponding to a single sequential operation.
A secondary vulnerability in objects/captcha.php exacerbates the primary race condition. The validation() method successfully validates a user-provided captcha but fails to destroy the session token ($_SESSION['palavra']) afterward. This oversight permits an attacker to solve a single captcha and reuse the established session state to authorize an arbitrary number of concurrent transfer requests.
The vulnerable implementation in plugin/YPTWallet/YPTWallet.php relies on distinct, non-isolated queries. The application reads the balance using a standard SELECT statement and later issues an UPDATE. No transaction boundary exists to group these operations, and no database locks prevent concurrent access to the targeted rows.
The patch introduced in commit 34132ad5159784bfc7ba0d7634bb5c79b769202d resolves this by enforcing strict database serialization. The developers introduced a new method, Wallet::getFromUserForUpdate(), which leverages the SQL SELECT ... FOR UPDATE syntax. This places an exclusive lock on the row, forcing concurrent queries to queue until the active transaction resolves.
// Patched logic implementing row-level locking
mysqlBeginTransaction();
$wallet = Wallet::getFromUserForUpdate($users_id);
if ($wallet->getBalance() < $amount) {
mysqlRollback();
return false;
}
// Proceed with update and commit...Additionally, the patch addresses the token reuse vulnerability within objects/captcha.php. By explicitly unsetting the session variable upon successful validation, the application ensures that each captcha token is strictly single-use. The frontend view plugin/YPTWallet/view/transferFunds.php was also updated to force a captcha refresh after every submission attempt.
// Captcha validation fix
if (strcasecmp($_SESSION['palavra'], $captcha) == 0) {
unset($_SESSION['palavra']); // Ensures single-use
return true;
}Exploiting this TOCTOU race condition requires an attacker to synchronize multiple HTTP requests precisely. The attacker must first authenticate to the AVideo application and obtain a valid session cookie. They must then navigate to the transfer interface and solve the mandatory captcha, capturing the valid request payload.
To bypass PHP's default file-based session locking, which typically serializes requests from the same session ID, the attacker must establish multiple independent authenticated sessions. The failure to invalidate the captcha token allows the attacker to broadcast the exact same HTTP POST payload across all concurrent connections simultaneously.
Upon receiving the concurrent requests, the web server allocates separate worker threads. If the requests arrive within the same time window, multiple threads execute the SELECT query before any thread issues an UPDATE. The attacker successfully transfers multiples of their total balance to the designated recipient account, effectively synthesizing unauthorized funds.
The security impact of CVE-2026-34368 is strictly isolated to the integrity of the application's internal financial ledger. An attacker can arbitrarily inflate the balance of controlled recipient accounts without possessing the requisite sender funds. This constitutes a direct violation of the platform's business logic and financial trust model.
The CVSS v3.1 base score is calculated as 5.3 (Medium), reflecting the localized impact. The attack requires low privileges (an authenticated standard user) and no user interaction. However, the attack complexity is rated High because successful exploitation depends on precise network timing and the successful manipulation of concurrent HTTP state.
The vulnerability does not compromise the confidentiality or availability of the host system. The attacker cannot achieve remote code execution, access arbitrary database records, or disrupt platform services. The damage is confined to the specific trust boundaries of the YPTWallet plugin and the accuracy of user account balances.
System administrators must update WWBN AVideo installations to a version strictly greater than 26.0, or ensure that commit 34132ad5159784bfc7ba0d7634bb5c79b769202d is applied to their codebase. This patch introduces the necessary mysqlBeginTransaction() and SELECT ... FOR UPDATE mechanisms required to enforce atomic operations.
For organizations unable to deploy the update immediately, mitigating the risk requires disabling the YPTWallet plugin entirely. Since the vulnerability is inherent to the core transfer logic, no configuration changes or Web Application Firewall (WAF) rules can effectively prevent the race condition without breaking the underlying functionality.
Developers implementing similar financial transaction systems must ensure that all read-check-write sequences are encapsulated within database transactions. Utilizing row-level locking or optimistic concurrency control is mandatory to prevent TOCTOU vulnerabilities in concurrent environments. All authorization tokens, including captchas, must be aggressively invalidated immediately after their first successful use.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
AVideo WWBN | <= 26.0 | > 26.0 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-362 |
| Attack Vector | Network |
| CVSS Score | 5.3 (Medium) |
| EPSS Score | 0.00026 |
| Impact | Integrity Violation (Double-Spending) |
| Exploit Status | Proof of Concept |
| KEV Status | Not Listed |
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another concurrent code sequence that is operating improperly.