GHSA-8whc-2wmv-ww35: Unauthenticated Stored DOM-based Cross-Site Scripting in WWBN AVideo YPTSocket Plugin

The WWBN AVideo video-sharing platform supports real-time features through its YPTSocket plugin. This plugin utilizes ReactPHP and the Ratchet WebSocket library to establish communication tunnels between browsers and the backend server. These real-time sockets coordinate live-stream viewers, synchronized video playback, and server-to-client notifications. The socket architecture maintains connection lists and tracks metadata for every online user.

To manage connected clients, the YPTSocket service processes incoming connection parameters and registers each connection session. Unauthenticated users can request connection tokens and join the WebSocket daemon. Because the connection registration endpoint does not validate metadata values passed during the handshake, an unauthenticated client can supply arbitrary strings as their location, active page, or page title parameters.

This lack of validation exposes an attack surface where input values are trusted implicitly and written to the application's transient state storage. Because the application broadcasts this metadata to administrative dashboards without sanitization, it establishes a stored DOM-based Cross-Site Scripting (XSS) pathway. This allows unauthenticated external actors to target privileged application users who are viewing dynamic administration control panels.

The core flaw exists within the ingestion logic of the WebSocket server and the corresponding handling routine in the client-side JavaScript engine. When a WebSocket connection handshake occurs, the YPTSocket server parses parameters directly from the connection query string. Specifically, inside plugin/YPTSocket/MessageSQLiteV2.php, the method onOpen extracts the raw HTTP query string via the connection URI and deserializes the parameters into variables.

The server fails to sanitize the input values from webSocketSelfURI and page_title before adding them to the connection state dictionary. The parameter page_title is processed through the standard PHP function utf8_encode(), which standardizes encoding characters to UTF-8 but performs zero neutralization or character validation. Similarly, the webSocketSelfURI value is loaded directly into the client dictionary without filtering or scheme checking. This state dictionary is immediately written to an in-memory SQLite database, which is used to cache user connection records.

The database persistence step renders this vulnerability a stored DOM-based flaw. The ReactPHP event loop periodically reads these entries from SQLite and broadcasts them to all other connected clients. On the frontend, plugin/YPTSocket/script.js processes this broadcast payload dynamically. The client application takes the unescaped strings and dynamically constructs an HTML anchor element inside template literals, inserting them directly into the active browser DOM. Because the frontend relies on the unsafe jQuery .append() function, the browser parses the unescaped payload as active HTML and executes any script contexts embedded within it.

Prior to the patch, the connection metadata processing in plugin/YPTSocket/MessageSQLiteV2.php did not sanitize input parameters before database insertion. The vulnerable assignment logic for the client connection metadata is structured as follows:

// Vulnerable server-side registration logic
if (!empty($wsocketGetVars['webSocketSelfURI'])) {
    $client['selfURI'] = $wsocketGetVars['webSocketSelfURI'];
} else {
    $client['selfURI'] = $json->selfURI;
}
 
$client['isCommandLine'] = @$wsocketGetVars['isCommandLine'];
$client['page_title'] = @utf8_encode(@$wsocketGetVars['page_title']);

The corresponding client-side display logic in plugin/YPTSocket/script.js processes these parameters in the user interface card builder. The values are concatenated into a string template literal and outputted into the DOM using an unsafe sink:

// Vulnerable client-side DOM manipulation sink
if (userData.page_title) {
    textParts.push(userData.page_title);
}
const finalText = textParts.join(' ');
 
const html = `
    <a href="${selfURI}" target="_blank"
    class="${className} btn btn-primary btn-sm btn-block mb-1"
    data-resource-id="${resourceId}"
    data-toggle="tooltip"
    title="${tooltip}"
    >
        <i class="far fa-compass"></i> ${finalText}
    </a>`;
 
$(`#${socketUserDivID} .socketUserPages`).append(html);

The use of jQuery's .append() with finalText and selfURI enables immediate injection. If page_title contains HTML markup (e.g., an image tag with an onerror script handler), jQuery parses it as an executable DOM tree element. If selfURI contains quote marks, an attacker can break out of the href attribute context to inject event handlers (e.g., onload, onmouseover) or execute the target script immediately using the javascript: pseudo-protocol scheme.

An attacker can exploit this vulnerability without any prior authentication on the AVideo application. The first prerequisite is obtaining a valid WebSocket token, which the application issues to any visitor, including guest sessions. This token is acquired by querying the public endpoint /plugin/YPTSocket/getWebSocket.json.php.

Once the token is retrieved, the attacker initiates a standard WebSocket connection to the application socket server, appending the injection payload within the connection parameters of the WebSocket handshake query string. The attacker can deliver two distinct vectors within a single connection: an HTML element breakout via the page_title parameter, or a URI-based protocol payload via the webSocketSelfURI parameter.

Once the handshake is completed, the YPTSocket server stores the active connection state containing the unescaped payloads. The server then transmits a NEW_CONNECTION message to all online clients. When any administrative user opens or interacts with an administrative panel that displays active client cards, the client-side JavaScript engine receives the serialized payload and runs .append(). This forces the administrative user's browser to execute the injection code silently, allowing actions like credential harvesting, session hijacking, or automated server modifications.

This vulnerability carries a CVSS score of 8.8 (High Severity), as it allows unauthenticated execution of remote scripting commands inside targeted administrative sessions. The impact of successful exploitation is complete compromise of the affected user's session context. If the targeted user has administrative permissions, the attacker can hijack active browser sessions, steal administrative session tokens, and bypass Multi-Factor Authentication (MFA) via dynamic browser proxying.

Because AVideo is configured to allow administrators to configure system settings, install plugins, and execute command-line shell updates, session hijacking at this tier translates directly to Remote Code Execution (RCE) on the underlying server host. This can be achieved by utilizing the hijacked administrative session to upload a malicious PHP web shell or modify core system execution settings.

Furthermore, this vulnerability acts as a highly reliable attack path because of the stored nature of the payload. The attacker does not need to phish the administrator or trick them into clicking a specific link. The attacker merely connects to the public-facing socket, and the platform delivers the payload to the administrator's dashboard. This completely circumvents traditional client-side mail filters and network-level firewalls that inspect incoming HTTP request bodies.

To remediate this vulnerability, developers must restrict parameters during server-side database insertion and ensure the client-side presentation layer does not evaluate strings as code. The patch applied to plugin/YPTSocket/MessageSQLiteV2.php implements verification logic to validate the structure of the input variables.

The server-side fix filters incoming URI values and encodes text sequences securely. It processes page_title parameters with htmlspecialchars configured with the ENT_QUOTES | ENT_HTML5 flags to sanitize tag delimiters. Additionally, the updated registration handler validates the structure of webSocketSelfURI to ensure it represents a valid URL using FILTER_VALIDATE_URL and matches an allowed HTTPS scheme.

// Patched server-side registration logic
if (!empty($wsocketGetVars['webSocketSelfURI'])) {
    $rawURI = $wsocketGetVars['webSocketSelfURI'];
    if (filter_var($rawURI, FILTER_VALIDATE_URL) && preg_match('/^https?:\/\//i', $rawURI)) {
        $client['selfURI'] = $rawURI;
    } else {
        $client['selfURI'] = $json->selfURI;
    }
} else {
    $client['selfURI'] = $json->selfURI;
}
$client['page_title'] = htmlspecialchars((string)@$wsocketGetVars['page_title'], ENT_QUOTES | ENT_HTML5, 'UTF-8');

While this server-side sanitization prevents the storage of raw HTML payloads, long-term security relies on updating the frontend script. Developers should refactor client-side code to replace jQuery's unsafe .append() sink with safe, native DOM APIs such as element.textContent or jQuery's safer .text() method to prevent raw strings from being executed as active HTML markup.