CVE-2026-116206 in YesWiki
Summary
by MITRE • 10/25/2026
YesWiki from 4.2.0 before 4.7.0 contains a stored cross-site scripting vulnerability that allows authenticated users to inject script into comment bodies using the wakka raw-HTML syntax. Attackers can post comments via the /api/comments endpoint that render unescaped through the Twig raw filter, executing JavaScript in administrators' and visitors' sessions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
YesWiki versions ranging from 4.2.0 up to but not including 4.7.0 are susceptible to a stored cross-site scripting vulnerability within its comment handling mechanism. This security flaw arises specifically when authenticated users utilize the wakka raw-HTML syntax to inject malicious script payloads into comment bodies. The core technical deficiency lies in how the application processes and renders these inputs through the Twig templating engine. Although the input is accepted from an authenticated user, it is subsequently rendered using the Twig raw filter without adequate sanitization or escaping of potentially dangerous HTML tags and JavaScript event handlers. This configuration allows arbitrary code execution within the context of any other user who views the compromised comment, effectively bypassing standard content security policies that might otherwise mitigate such attacks in less permissive configurations.
The operational impact of this vulnerability is significant because it enables persistent data manipulation and session hijacking scenarios. An attacker with valid credentials can post a maliciously crafted comment via the /api/comments endpoint or through the web interface using the specific raw-HTML syntax. Once stored, this payload remains active in the database until manually removed by an administrator. When other users, including high-privilege administrators or regular visitors, load pages containing these comments, their browsers execute the injected JavaScript code. This execution occurs within the same origin context as the YesWiki application, granting the attacker access to sensitive session cookies, authentication tokens, and potentially user-specific data stored in local storage or accessed via DOM manipulation. The persistence of this attack vector means that a single successful injection can compromise multiple users over an extended period without further action from the initial attacker.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it represents a stored or persistent XSS variant where malicious scripts are permanently stored on the target server and later executed in the browsers of other users. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1059, Command and Scripting Interpreter, particularly sub-techniques involving JavaScript execution within web applications. The attack path typically involves initial access through valid credentials followed by privilege escalation or data exfiltration via the injected script, potentially leading to full account compromise if session tokens are stolen and replayed.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For organizations running affected versions, upgrading to YesWiki version 4.7.0 or later is the primary recommendation as it resolves this specific rendering issue by implementing proper output encoding for all user-supplied content regardless of the input method used. In cases where an upgrade is not immediately feasible, administrators should enforce strict Content Security Policy headers that restrict script execution from untrusted sources and disable inline scripts if possible. Additionally, applying server-side validation to reject inputs containing raw HTML tags when they are intended for plain text fields can provide a layer of defense in depth. It is also critical to audit existing comments for any previously injected payloads and remove them manually until the patch is applied. Regular security training for users regarding safe input practices and monitoring logs for unusual API activity patterns related to comment submissions can further reduce the risk surface associated with this vulnerability.