CVE-2026-116203 in YesWiki
Summary
by MITRE • 10/25/2026
YesWiki before 4.7.0 contains a stored cross-site scripting vulnerability in the filtertags action, which echoes attacker-controlled token values without output encoding. Anonymous attackers can inject markup via action-attribute parameters that bypasses the allow_raw_html gate, executing JavaScript for every page viewer.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The security flaw identified in YesWiki versions prior to 4.7.0 represents a critical stored cross-site scripting vulnerability located within the filtertags action module. This component is responsible for processing and rendering tags associated with wiki pages, but it fails to implement adequate output encoding when handling user-supplied input. Specifically, the application echoes attacker-controlled token values directly into the HTML response without sanitizing or escaping special characters that have semantic meaning in a browser context. Because this data originates from stored sources such as page content or configuration settings rather than immediate request parameters, the malicious payload persists on the server and is served to every user who views the affected page, significantly expanding the attack surface beyond single-session exploitation.
The technical mechanism of this vulnerability relies on the bypassing of existing security controls, specifically the allow_raw_html gate. This gate is designed to restrict the execution of raw HTML or JavaScript within wiki content to prevent common injection attacks. However, due to improper validation logic in the filtertags action, attackers can inject markup via action-attribute parameters that circumvent this restriction. By embedding malicious scripts within these attributes, an attacker ensures that when a victim loads the compromised page, their browser interprets and executes the injected JavaScript code as part of the legitimate document structure. This execution occurs in the context of the web application's domain, granting the script full access to cookies, session tokens, and other sensitive data protected by same-origin policies.
The operational impact of this vulnerability is severe due to its stored nature and broad reach. Unlike reflected XSS which requires tricking a user into clicking a malicious link, this flaw automatically affects every page viewer who accesses content containing the injected payload. Attackers can exploit this to steal session cookies, hijack active sessions, perform actions on behalf of authenticated users, or redirect victims to phishing sites. In environments where YesWiki is used for collaborative work or sensitive information sharing, such an attack could lead to unauthorized access to private documents, manipulation of page content through administrative privilege escalation if the victim has elevated rights, and a general compromise of user trust in the platform's integrity. The ability to execute arbitrary JavaScript also opens avenues for keylogging, credential harvesting, and further lateral movement within internal networks if single sign-on or shared credentials are utilized.
Mitigation strategies must prioritize immediate patching and robust input validation practices. Administrators should upgrade YesWiki to version 4.7.0 or later where this issue has been resolved through improved encoding mechanisms in the filtertags action. Until an update can be applied, temporary mitigations may include restricting access to wiki pages containing dynamic tags to trusted users only, although this is not a complete defense given the stored nature of the data. From a development perspective, implementing strict output encoding for all user-supplied data before rendering it in HTML contexts is essential. This aligns with CWE-79 Improper Neutralization of Input During Web Page Generation and ensures that special characters are converted to their corresponding HTML entities, preventing them from being interpreted as executable code by the browser.
Security testing frameworks such as MITRE ATT&CK classify this type of vulnerability under T1059 Command and Scripting Interpretation, specifically JavaScript execution within a web application context. Addressing this flaw requires adherence to secure coding standards that emphasize defense in depth, including content security policy headers to restrict script sources and regular code reviews focused on data flow analysis from input points to output sinks. By treating all user-controlled data as untrusted until explicitly validated and encoded, organizations can prevent similar stored XSS vulnerabilities across their web applications.