CVE-2026-120500 in Otter Wiki
Summary
by MITRE • 11/02/2026
An Otter Wiki before 2.26.2 contains a stored cross-site scripting vulnerability in OtterwikiMdRenderer.block_code that allows attackers who can edit pages, including anonymous users under the default configuration, to inject arbitrary script. Attackers can place HTML inside a math fenced code block, which is rendered unescaped and executes for every viewer of the page.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Otter Wiki versions prior to 2.26.2 represents a critical stored cross-site scripting flaw located within the markdown rendering engine, specifically affecting the handling of math fenced code blocks via the block_code function. This security defect arises from an insufficient sanitization process where user-supplied content intended for mathematical notation is processed without adequate validation or escaping mechanisms. When an attacker with edit privileges injects malicious HTML scripts into these specific code blocks, the application fails to neutralize the active elements before rendering them in the browser context of other users. This behavior indicates a fundamental failure in input validation and output encoding strategies within the markdown parser component responsible for processing LaTeX-style delimiters.
Under the default configuration settings of Otter Wiki, anonymous users are granted permission to edit pages, which significantly lowers the barrier for exploitation. An attacker does not require authentication or elevated privileges to initiate an attack; they can simply create a new page or modify an existing one containing the malicious payload within a math fenced code block. Once this content is saved and subsequently viewed by other legitimate users, the browser interprets the injected script as part of the trusted document object model. This results in the execution of arbitrary JavaScript code within the security context of the Otter Wiki domain for every viewer who accesses the compromised page.
The operational impact of this vulnerability extends beyond simple defacement or cookie theft. Because the payload is stored on the server and served to multiple victims, it facilitates a persistent attack vector that can lead to session hijacking, credential harvesting through keyloggers embedded in the script, or redirection to phishing sites designed to steal user credentials. In enterprise environments where Otter Wiki might be integrated with single sign-on systems or used for sensitive documentation, this vulnerability could serve as an initial access point for further lateral movement within a network if combined with other social engineering tactics. The persistence of the payload means that remediation requires not only patching the software but also auditing and cleaning existing pages to remove any injected malicious content from previous attacks.
From a classification perspective, this issue aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). The specific mechanism involves stored XSS where the payload is saved in a database or file system and later retrieved for display without proper encoding. In terms of adversary tactics, this vulnerability supports techniques associated with ATT&CK ID T1059 Command and Scripting Interpreter, specifically allowing attackers to execute scripts within a victim's browser session. It also relates to CWE-83 Improper Neutralization of Special Elements used in an HTML Document which highlights the failure to escape special characters that have meaning in HTML contexts.
Mitigation strategies must prioritize immediate software updates to version 2.26.2 or later where this rendering logic has been corrected to properly sanitize and encode output within math blocks. Administrators should also review access control policies to restrict page editing permissions, ensuring that only authenticated and authorized users can modify wiki content. Implementing a Content Security Policy header with strict directives regarding script execution sources can provide an additional layer of defense by preventing the injection and execution of unauthorized scripts even if they are present in the DOM. Regular security audits of user-generated content and automated scanning for XSS payloads should be integrated into the development lifecycle to prevent similar vulnerabilities from being introduced or exploited in future releases.