AVideo CVE-2026-116139

Requires an authenticated account that passes User::canComment() and has permission to watch the target video, comments must be displayed to other users, and a victim must actually view the malicious comment (UI:P/R). The payload must be structured as a leading HTML block whose first token is an <img> tag carrying an event handler (e.g. '<img src=x onerror=alert(1)>'); the advisory confirms that inline forms with a preceding prefix (e.g. 'prefix <img src="x" onerror="alert(1)">') ARE sanitized, so the leading-block position is a specific prerequisite. Limiting factors: attacker privilege (comment permission, not unauthenticated), required victim interaction, the specific leading-img payload shape, applicability only to versions 26.0-29.3.0 (25.0 unaffected), and a Content-Security-Policy that blocks inline event handlers, which mitigates this payload.

This is a moderate-severity stored XSS (CWE-79) with modest, well-bounded real-world risk rather than an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N, 5.1) and the vendor GHSA's CVSS 3.1 (5.4, AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) agree closely: network-reachable but requiring both attacker privileges (comment permission, PR:L) and victim interaction (viewing the comment, UI:P/R), with only low confidentiality and integrity impact and no availability impact. There is no KEV listing and no EPSS score in the provided data, so there is no signal of active or widespread exploitation; the vuln.today decision label is 'this_month', consistent with a prioritize-but-not-drop-everything posture. The strongest conflict in the inputs is patch status: the top-level metadata says 'Patch: Available from vendor' and lists commit f13587c as a patch reference, but the authoritative WWBN GHSA advisory states that this very commit is the regression that INTRODUCED the flaw (by disabling Parsedown safe mode) and that 'No verified patch or patched release was identified as of 2026-10-08,' explicitly noting that updating to 29.3.0 or master does not fix it - treat the 'patch available' metadata as unverified and defer to the vendor advisory. Exploitation evidence is renderer-level only: the advisory reproduced the sanitizer bypass with a standalone test but did not test live authenticated browser exploitation, and a CSP blocking inline event handlers mitigates the payload. Net: a genuine but privilege- and interaction-gated XSS in a niche product, not a high-CVSS-but-no-real-risk false alarm nor a critical emergency.

An attacker holding an ordinary account with permission to comment on a viewable video posts a comment beginning with a leading HTML image block such as '<img src=x onerror=alert(1)>'. Because markDownToHTML()'s block handler passes leading <img>/<a> tags to Parsedown's raw HTML handler without the inline sanitizer, the onerror handler survives rendering and executes in the AVideo origin when another user views the comment, enabling session-context actions or reading of accessible application data. A public PoC reference exists (the vendor advisory and VulnCheck), demonstrating the renderer bypass at the Parsedown level; it is not verified as working live browser exploitation, and a CSP that blocks inline event handlers can neutralize this specific payload.