Description

WWBN AVideo 29.0 through 29.4.0 contains a race condition vulnerability in plugin/PayPalYPT/ipn.php that allows attackers to bypass IPN replay protection due to a non-atomic deduplication check and insert. Attackers can concurrently replay a captured valid recurring-payment notification so both requests pass isRecurringPaymentIdUsed(), obtaining duplicate wallet credits and subscription renewals.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-11-06T15:17:17.763Z",
  "pubdate": "2026-11-06T15:17:17.763Z",
  "executiveSummary": "WWBN AVideo versions 29.0 through 29.4.0 contain a race condition vulnerability within the PayPalYPT plugin, specifically impacting the handling of Instant Payment Notification (IPN) messages.\nThe vulnerability originates from a non-atomic deduplication mechanism, allowing an attacker to bypass IPN replay protection.\nBy issuing concurrent requests containing valid recurring-payment notifications, an attacker can trick the system into accepting the same transaction multiple times.\nSuccessful exploitation results in unauthorized financial gain, specifically the improper crediting of user wallets and the illegitimate renewal of subscription services.\nThis flaw represents a significant risk to the integrity of the platform's billing and subscription management systems.\nThe vulnerability is exploitable by remote, unauthenticated attackers who possess a previously captured valid payment notification, requiring minimal technical effort to synchronize concurrent requests.",
  "technicalDetails": "The vulnerability resides in plugin/PayPalYPT/ipn.php, which is responsible for processing PayPal IPN messages to facilitate recurring payments. The core of the issue is a Time-of-Check to Time-of-Use (TOCTOU) race condition during the validation of transaction uniqueness.\nThe application utilizes a function, isRecurringPaymentIdUsed(), to verify whether a specific PayPal transaction ID has already been processed to prevent replay attacks. The logic follows a pattern of checking the database for the existence of the transaction ID and subsequently inserting the new record if it is not found.\nThe vulnerability exists because these two operations—the check for existing transaction IDs and the subsequent insertion of the new record—are performed non-atomically. In a multi-threaded or multi-process web server environment, if an attacker sends multiple, nearly simultaneous requests containing the same valid PayPal transaction identifier, both requests may execute the isRecurringPaymentIdUsed() check before either process completes the database write operation.\nConsequently, both concurrent requests will receive a 'false' response from the check function, indicating the transaction ID is unique. Both execution threads proceed to process the IPN logic, leading to duplicate database records and the redundant execution of payment fulfillment actions.\nThe attack flow involves the following steps: First, an attacker intercepts or captures a valid, successful IPN notification message from a legitimate recurring payment. Second, the attacker crafts a set of concurrent requests using this captured payload, utilizing tools to ensure the requests arrive at the server simultaneously to maximize the probability of the race condition window. Third, upon receiving the concurrent requests, the server-side logic in ipn.php fails to lock the database row or utilize atomic database-level operations to synchronize access to the transaction log. Fourth, the application logic executes the business processes (e.g., adding credit to a wallet) for every concurrent request that passes the initial, flawed deduplication check.\nThis vulnerability is present in versions 29.0 through 29.4.0. It requires no specific authentication or elevated privileges, as IPN endpoints must remain accessible to payment provider callbacks. The impact is significant, leading to direct financial loss and the potential for large-scale subscription abuse."
}