CVE-2026-116823 in YesWiki
Summary
by MITRE • 10/27/2026
YesWiki before 4.7.0 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject JavaScript by supplying query parameters matching missing Bazar field names. Attackers can craft links where BazarField::getValue() falls back to unsanitized $_REQUEST values rendered via Twig |raw templates, performing same-origin authenticated actions in victims' sessions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in YesWiki versions prior to 4.7.0 represents a critical reflected cross-site scripting flaw rooted in the application's handling of form field data within its Bazar module. This security defect allows unauthenticated remote attackers to inject malicious JavaScript code into web pages viewed by other users. The root cause lies in how the system processes query parameters that correspond to missing or undefined Bazar field names. When a user accesses a URL with specific query strings intended for non-existent fields, the application does not properly validate or sanitize these inputs before rendering them back to the client browser.
Technically, the flaw occurs within the BazarField::getValue() method which serves as a fallback mechanism for retrieving form data. In scenarios where a requested field name is not found in the standard configuration, this function defaults to fetching values directly from the global $_REQUEST superglobal array without applying adequate sanitization measures. These unsanitized values are then passed through Twig templates using the |raw filter directive. The use of raw rendering explicitly instructs the template engine to output the content as-is, bypassing any automatic HTML escaping that would normally neutralize script tags and event handlers. Consequently, if an attacker crafts a malicious link containing JavaScript payloads within these query parameters, the browser will execute this code in the context of the victim's session when they visit the crafted URL.
The operational impact of this vulnerability is significant due to its potential for facilitating account takeover and data exfiltration attacks. Since the injected script executes with the same origin as the vulnerable application, it inherits all cookies, local storage contents, and authentication tokens associated with that domain. An attacker can leverage this capability to perform actions on behalf of a logged-in victim without their knowledge or consent. This includes but is not limited to changing user settings, posting malicious content, transferring funds if financial transactions are supported, or stealing sensitive personal information displayed within the application interface. The attack vector requires only social engineering via a crafted link, making it highly effective against users who may trust links from known domains even if they appear slightly altered in their query strings.
From an industry standard perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it falls under the reflected variant where the malicious script is part of a request sent to the web server and immediately returned in the response. In terms of attack tactics, this maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter via browser-based execution, allowing adversaries to interact with user sessions dynamically. The lack of input validation on query parameters further highlights deficiencies consistent with CWE-20 Improper Input Validation which permits the injection of unintended code into the application logic flow.
To mitigate this vulnerability, immediate updates to YesWiki version 4.7.0 or later are required as these releases address the sanitization issues within the Bazar module. For organizations unable to patch immediately, implementing a Web Application Firewall with rulesets capable of detecting and blocking reflected XSS payloads in query parameters can provide temporary protection. Additionally developers should enforce strict output encoding for all dynamic content rendered by Twig templates avoiding the use of raw filters unless absolutely necessary and ensuring that data from $_REQUEST is validated against an allowlist of expected field names before processing. Regular security audits focusing on input handling mechanisms will help prevent similar flaws in future development cycles.