Summary 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. Details 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'). PoC 1. Set up a vulnerable YesWiki instance with the bundled Bazar extension enabled. This was validated locally on the official "doryphore 4.6.5" release. 2. Confirm the minimum access requirements: - No account is required. - No "read" or "write" permission on a specific page is required. - No valid existing page tag is required. - No valid Bazar form identifier is required. - The only observed requirements were that the Bazar widget handler is present and the request includes an "id" parameter. 3. Request the widget handler with an attribute-breaking payload in "id", for example: http://127.0.0.1:8085/NoSuchPage/widget?id=%22%20onmouseover=%22alert(1)%22%20x=%22 4. Open the URL in a browser as an unauthenticated visitor. 5. Observe that the server returns HTTP "200" and renders the Bazar widget page even though the page tag is arbitrary. 6. Inspect the returned HTML. The response contains attacker-controlled attributes in the widget root element: <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="" > 7. Move the mouse over the "widgetapp" element or otherwise trigger the injected event handler. 8. The browser executes the injected JavaScript in the YesWiki origin. <img width="1600" height="838" alt="image" src="https://github.com/user-attachments/assets/de592586-a6ee-48f4-bbde-137ab07aaa71" />Impact This is a reflected XSS vulnerability in the Bazar widget handler with very low attacker prerequisites. The practical access model is: - The attacker only needs to send a crafted public URL. - The victim does not need to authenticate. - The attacker does not need edit rights, ownership, or a valid page tag. - The route only needs to be reachable on a YesWiki instance with Bazar enabled. An attacker may be able to: - Execute arbitrary JavaScript in the victim's browser. - Steal browser-accessible sensitive data. - Perform actions in the victim's session if the victim is logged in. - Target public visitors and authenticated users alike because the route is reachable without access-control checks.