Description

AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a stored cross-site scripting vulnerability in the YPTWallet plugin where user-supplied CryptoWallet values are base64-encoded but not HTML-escaped before storage in wallet_log.information. Administrators viewing pending withdrawal requests in pendingRequests.php execute the stored markup in their session, allowing attackers to perform administrative actions via same-origin fetch requests.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.7",
  "pubDate": "2026-09-11T12:16:54.890Z",
  "pubdate": "2026-09-11T12:16:54.890Z",
  "executiveSummary": "AVideo, up to commit c3edcc274c389816d434acadac07ee78eaf330c1, contains a Stored Cross-Site Scripting (XSS) vulnerability within the YPTWallet plugin.\nThe vulnerability originates from insufficient input sanitization of the CryptoWallet field, which is stored in the wallet_log.information database column.\nAn attacker can inject malicious JavaScript by providing a base64-encoded payload that, when rendered, executes in the administrative context.\nThe impact is significant, as an attacker can perform unauthorized administrative actions, manipulate the application, or steal session tokens through same-origin fetch requests.\nThis vulnerability poses a high risk to organizational security, as the exploitation is triggered automatically when an administrator views pending withdrawal requests within the pendingRequests.php administrative interface.\nNo specific authentication bypass is required; however, the attacker must be able to interact with the wallet withdrawal functionality to trigger the storage of the malicious payload.",
  "technicalDetails": "The root cause of this vulnerability is improper handling of user-supplied data within the YPTWallet plugin. When a user submits a CryptoWallet address, the application processes the input and stores it within the wallet_log table under the 'information' column.\nAlthough the input is base64-encoded prior to storage, the application fails to perform subsequent HTML-entity encoding or sanitization before rendering the content in the administrative panel.\nWhen an administrator accesses the pendingRequests.php file, the application decodes the stored base64 information and embeds the raw, malicious markup directly into the Document Object Model (DOM) of the administrator's browser session.\nBecause the payload is rendered within the administrative context, the injected JavaScript executes with the same-origin privileges of the administrator, allowing it to interact with the application’s administrative APIs.\nAn attacker can leverage this execution flow to craft a payload that performs arbitrary administrative actions via same-origin fetch requests, such as modifying system settings, escalating privileges, or exfiltrating sensitive data stored in the current session or localStorage.\nThe attack flow follows these steps: First, an attacker submits a withdrawal request with a crafted, base64-encoded malicious JavaScript payload in the CryptoWallet field. Second, the YPTWallet plugin stores this value in the database. Third, the administrator navigates to the 'pendingRequests.php' page to review the withdrawal. Fourth, the server-side script retrieves the malicious string from the 'wallet_log.information' field, decodes it, and renders it inside the administrator's page. Fifth, the browser executes the injected script, granting the attacker unauthorized control over the administrative session.\nThis vulnerability is classified as stored XSS, as the malicious code persists in the database until manually removed or overwritten. The lack of Content Security Policy (CSP) or adequate output encoding at the presentation layer facilitates the execution of the payload."
}