Packagist · yeswiki/yeswiki
YesWiki Vulnerable to Reflected XSS via Unescaped `id` Parameter in Bazar Widget HTML Attributes
YesWiki's Bazar widget handler reflects the id GET parameter into HTML attributes using strip_tags() only. Because strip_tags() does not escape double quotes, an attacker can break out of the attribute value, inject an event handler such as onmouseover, and execute arbitrary JavaScript in the victim's browser.
This issue is reachable without authentication. During validation, the vulnerable widget route returned the injected HTML for both /HomePage/widget?id=... and /NoSuchPage/widget?id=..., which shows that no login, no page ownership, no edit rights, and not even a valid page tag were required. The only routing prerequisite observed was that the Bazar extension is enabled and the request includes an id parameter.
The primary sink is in tools/bazar/presentation/templates/widget.tpl.html around lines 4-7, where $_GET['id'] is inserted into the data-formid attribute:
data-formid="<?php echo strip_tags($_GET['id']); ?>"
strip_tags() is not an output-encoding function. It removes HTML tags, but it does not escape characters such as double quotes, so an attacker can terminate the data-formid attribute and inject new attacker-controlled attributes.
The route is served by tools/bazar/handlers/__WidgetHandler.php around lines 14-26, which only checks whether $_GET['id'] is present:
if (!isset($_GET['id'])) {
return null;
}
No HasAccess('read'), HasAccess('write'), or authentication check is performed before the vulnerable template is rendered.
There is also a second reflection path in the same handler. The handler builds:
$urlParams = 'id=' . strip_tags($_GET['id']) . ...
and then places the resulting value into the widget template's data-iframeUrl attribute:
data-iframeUrl="<?php echo $GLOBALS['wiki']->href('bazariframe', '', $urlparams, false); ?>"
During validation, a single payload injected into id was reflected into both data-formid and data-iframeUrl, which confirms that the handler exposes multiple attribute-level sinks from the same unsafely handled input.
This issue maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
doryphore 4.6.5 release.read or write permission on a specific page is required.id parameter.id, for example:http://127.0.0.1:8085/NoSuchPage/widget?id=%22%20onmouseover=%22alert(1)%22%20x=%22
200 and renders the Bazar widget page even though the page tag is arbitrary.<div id="widgetapp" v-cloak
data-formid="" onmouseover="alert(1)" x=""
...
data-iframeUrl="http://127.0.0.1:8085/NoSuchPage/bazariframe&id=" onmouseover="alert(1)" x=""
>
widgetapp element or otherwise trigger the injected event handler.This is a reflected XSS vulnerability in the Bazar widget handler with very low attacker prerequisites.
The practical access model is:
An attacker may be able to:
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.