GHSA-8WHC-2WMV-WW35: Partial fix for YPTSocket stored DOM XSS

Vulnerability

GHSA-8WHC-2WMV-WW35 describes an unauthenticated stored DOM-based cross-site scripting issue in the WWBN AVideo YPTSocket plugin. The vulnerable code accepted attacker-controlled WebSocket handshake parameters and stored them without meaningful validation or output-safe encoding. In the referenced change, two fields are relevant: webSocketSelfURI and page_title. Before the patch, webSocketSelfURI was assigned directly into $client['selfURI'], enabling malicious schemes such as javascript: to persist into later DOM usage. Likewise, page_title was only passed through utf8_encode, which is not an XSS mitigation and does not neutralize HTML or script-bearing payloads.

The advisory impact is consistent with a stored client-side injection path: attacker input is persisted server-side and later rendered or consumed by privileged users, enabling session theft or administrative action execution when the data reaches a browser sink. The commit at the GitHub code reference shows the vulnerable trust boundary at WebSocket parameter ingestion.

$client['selfURI'] = $wsocketGetVars['webSocketSelfURI'];
$client['page_title'] = @utf8_encode(@$wsocketGetVars['page_title']);

Patch

The patch introduces two defensive changes in plugin/YPTSocket/MessageSQLiteV2.php as shown in the commit. First, it validates webSocketSelfURI with FILTER_VALIDATE_URL and additionally constrains the scheme to http or https using a regular expression. If validation fails, the code falls back to $json->selfURI instead of storing the attacker-supplied value. Second, it replaces the ineffective utf8_encode handling for page_title with htmlspecialchars(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'), which is appropriate for HTML text and attribute contexts where entity encoding is expected.

$rawURI = $wsocketGetVars['webSocketSelfURI'];
// Only accept http/https URIs to prevent javascript: href injection
if (filter_var($rawURI, FILTER_VALIDATE_URL) && preg_match('/^https?:\/\//i', $rawURI)) {
    $client['selfURI'] = $rawURI;
} else {
    $client['selfURI'] = $json->selfURI;
}
$client['page_title'] = htmlspecialchars((string)@$wsocketGetVars['page_title'], ENT_QUOTES | ENT_HTML5, 'UTF-8');

Technically, this patch moves the code from raw storage of untrusted values toward constrained storage. The URI fix is especially targeted at the advisory's stated javascript: injection vector. The title fix ensures that HTML metacharacters are encoded before persistence, reducing the chance that later HTML rendering will interpret attacker input as markup.

Review

Pros

The patch directly addresses the concrete exploit primitive identified in the advisory: untrusted URI data being stored and later used in a browser-relevant context. Restricting selfURI to validated http/https URLs is a strong mitigation against scheme-based payloads such as javascript:, which are common in href-driven DOM XSS chains. The fallback behavior also avoids preserving obviously invalid attacker input.

The page_title change is materially better than the prior implementation. utf8_encode only transforms character encoding and provides no XSS protection, whereas htmlspecialchars with quotes enabled is a real output-safety control for HTML contexts. The explicit UTF-8 charset and HTML5 flags are sensible defaults.

The patch is minimal and low-risk from a compatibility perspective. It changes only the ingestion logic for the two shown fields and does not introduce complex parsing or broad behavioral changes.

Cons

The fix is narrow and sink-specific based on the visible diff. It demonstrates protection for selfURI and page_title, but the advisory describes a broader stored DOM-based XSS condition originating from WebSocket handshake parameters. The patch does not establish a generalized validation policy for all handshake-derived fields, nor does it show a systematic audit of every downstream DOM sink.

The fallback to $json->selfURI is only as safe as that value's provenance. If $json->selfURI can also be influenced upstream or later consumed in unsafe contexts, the patch may reduce but not eliminate exploitability. The commit snippet does not prove end-to-end safety for that alternate source.

Encoding page_title at storage time can be effective for the known rendering path, but it is context-dependent. If the same stored value is later inserted into JavaScript, URL, or already-encoded HTML contexts, storage-time HTML encoding may be insufficient or may create inconsistent handling. Robust XSS prevention usually pairs input validation with context-appropriate output encoding at the final sink.

The URI validation allows any syntactically valid http/https URL. That blocks the documented scheme injection, but it does not constrain host, path, or application-specific trust expectations. If later code assumes same-origin or internal-only navigation semantics, additional policy checks may still be needed.

Verdict

Partial fix.

The patch credibly mitigates the specific stored DOM XSS vector evidenced by the diff and called out in the advisory, especially the javascript: URI injection path. However, the remediation is localized rather than architectural: it hardens two fields but does not demonstrate comprehensive sink review, broader handshake parameter validation, or end-to-end output-context guarantees. For engineers assessing closure, this looks sufficient to block the shown exploit path, but not strong enough from the available evidence to classify as a root-cause eradication across the plugin.

Recommended follow-up is to audit all WebSocket handshake parameters and all browser-facing consumers, enforce allowlists for any navigational URLs, and apply context-specific encoding at render time in addition to storage-side normalization. The primary sources for this assessment are the fixing commit, the GitHub Security Advisory, and the mirrored report at cvereports.com.