CVE-2026-34368: Wwbn Avideo Race Condition Vulnerability

CVE-2026-34368 Overview

WWBN AVideo is an open source video platform that contains a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability in its YPTWallet plugin. In versions up to and including 26.0, the transferBalance() method in plugin/YPTWallet/YPTWallet.php performs balance verification and deduction operations without proper database transaction handling or row-level locking, enabling authenticated attackers to exploit concurrent transfer requests for financial manipulation.

Critical Impact

Attackers with authenticated access can exploit this race condition to multiply wallet credits by sending concurrent transfer requests, resulting in financial loss to the platform and potential service abuse.

Affected Products

• WWBN AVideo versions up to and including 26.0
• YPTWallet plugin component (plugin/YPTWallet/YPTWallet.php)
• All platforms running vulnerable AVideo installations with wallet functionality enabled

Discovery Timeline

• 2026-03-27 - CVE-2026-34368 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-34368

Vulnerability Analysis

This vulnerability represents a classic Time-of-Check-Time-of-Use (TOCTOU) race condition within the wallet transfer functionality of the AVideo platform. The fundamental flaw exists in the transferBalance() method where the application performs a non-atomic sequence of operations: reading the sender's current wallet balance, verifying sufficient funds in PHP application code, and then writing the updated balance back to the database.

The absence of database transactions and row-level locking creates a critical window of opportunity for exploitation. When multiple authenticated sessions initiate concurrent transfer requests, each request independently reads the same stale balance value before any deduction is committed. All concurrent requests pass the balance sufficiency check because they reference the original balance amount, resulting in only one deduction being applied while the recipient account receives multiple credits.

This attack requires the attacker to maintain multiple authenticated sessions (either through the same account or coordinated compromised accounts) and the ability to send precisely timed concurrent HTTP requests to exploit the race window effectively.

Root Cause

The root cause is the lack of proper concurrency controls in the wallet transaction logic. The transferBalance() method performs a read-modify-write sequence without atomic database transactions or SELECT ... FOR UPDATE row-level locking. This allows multiple concurrent requests to read the same balance value and pass validation independently, violating the expected invariant that a user cannot transfer more funds than they possess.

Attack Vector

The attack vector is network-based and requires low-privileged authenticated access to the AVideo platform. An attacker must have valid credentials and the ability to establish multiple concurrent sessions. The attack involves:

1. Authenticating to the AVideo platform with multiple sessions
2. Identifying the wallet transfer endpoint
3. Crafting concurrent transfer requests for amounts up to the current balance
4. Timing the requests to exploit the race window between balance check and deduction

The following patch demonstrates the fix implemented to address this vulnerability by adding a SELECT ... FOR UPDATE mechanism:

    /**
     * Like getFromUser() but issues SELECT … FOR UPDATE to lock the row.
     * Must be called inside an active transaction (mysqlBeginTransaction()).
     * Returns a populated Wallet object, or false if the row does not exist.
     */
    static function getFromUserForUpdate($users_id) {
        global $global;
        $users_id = intval($users_id);
        $stmt = $global['mysqli']->prepare(
            "SELECT * FROM " . static::getTableName() . " WHERE users_id = ? LIMIT 1 FOR UPDATE"
        );
        $stmt->bind_param("i", $users_id);
        $stmt->execute();
        $row = $stmt->get_result()->fetch_assoc();
        $stmt->close();
        if (empty($row)) {
            return false;
        }
        $wallet = new static(0);
        foreach ($row as $key => $value) {
            @$wallet->$key = $value;
        }
        return $wallet;
    }

Source: GitHub AVideo Commit

Detection Methods for CVE-2026-34368

Indicators of Compromise

• Multiple concurrent transfer requests from the same user or IP address within milliseconds
• Wallet balance discrepancies where total credits exceed total debits for a user
• Unusual patterns of rapid, repeated transfer operations targeting the same recipient
• Database logs showing multiple concurrent SELECT operations on wallet tables without corresponding UPDATE locks

Detection Strategies

• Implement rate limiting detection on the wallet transfer API endpoint to flag abnormally high request volumes
• Monitor database transaction logs for concurrent read operations on wallet balance records
• Deploy anomaly detection to identify users whose received credits exceed mathematically possible transfers
• Audit wallet transaction history for patterns consistent with race condition exploitation (multiple identical transfers within sub-second timeframes)

Monitoring Recommendations

• Enable detailed application logging for all transferBalance() method invocations including timestamps and session identifiers
• Implement database-level auditing on the YPTWallet tables to track all read and write operations
• Configure alerting for unusual transaction patterns such as multiple identical transfer amounts within short time windows
• Regularly reconcile wallet balances against transaction history to detect exploitation after the fact

How to Mitigate CVE-2026-34368

Immediate Actions Required

• Upgrade to AVideo version containing commit 34132ad5159784bfc7ba0d7634bb5c79b769202d or later
• Audit existing wallet transactions for evidence of exploitation (balance discrepancies, duplicate credits)
• Consider temporarily disabling the YPTWallet transfer functionality until the patch is applied
• Review and strengthen authentication controls to limit the ability to maintain multiple concurrent sessions

Patch Information

WWBN has released a security fix in commit 34132ad5159784bfc7ba0d7634bb5c79b769202d. This patch introduces proper row-level locking using SELECT ... FOR UPDATE statements wrapped in database transactions, ensuring atomic balance checks and updates. Additionally, the patch enhances captcha token handling to prevent reuse within the same session, adding another layer of protection against automated exploitation attempts.

For detailed patch information, refer to the GitHub Security Advisory GHSA-h54m-c522-h6qr and the GitHub AVideo Commit.

Workarounds

• Implement application-level rate limiting on the wallet transfer endpoint to prevent rapid concurrent requests
• Add a unique transaction token requirement that must be validated server-side before processing transfers
• Temporarily disable the wallet transfer feature if immediate patching is not possible
• Deploy a Web Application Firewall (WAF) rule to throttle concurrent requests to the transfer endpoint

# Configuration example for rate limiting via nginx (temporary mitigation)
# Add to your nginx server block for the AVideo installation

location /plugin/YPTWallet/ {
    limit_req zone=wallet_limit burst=2 nodelay;
    # Limits requests to 1 per second per IP with burst of 2
    proxy_pass http://backend;
}

# Define the rate limit zone in http block
# limit_req_zone $binary_remote_addr zone=wallet_limit:10m rate=1r/s;