CVE-2026-120203 in ShowDoc
Summary
by MITRE • 10/31/2026
ShowDoc 2.8.14 before 3.9.6 contains a code injection vulnerability in its Mock feature that allows authenticated users to execute shell commands through mockjs templates. Attackers can store a template via MockController::add with escaped parentheses that mockjs evaluates with eval(), then trigger it through MockController::infoByKey to run commands, as root in the official Docker image.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
ShowDoc versions prior to 3.9.6 contain a critical code injection vulnerability within its Mock feature, specifically affecting version 2.8.14 and earlier releases up to this threshold. This flaw stems from improper neutralization of special elements used in an expression language, allowing authenticated users to inject arbitrary commands into the application environment. The vulnerability is rooted in how the software handles mockjs templates, which are designed to simulate API responses for development purposes but inadvertently provide a vector for remote code execution when input validation and sanitization mechanisms are insufficiently rigorous.
The technical mechanism of exploitation involves two primary steps orchestrated by an authenticated attacker. First, the adversary utilizes the MockController::add endpoint to store a malicious mockjs template. This step requires careful construction of the payload using escaped parentheses to bypass initial filtering or parsing logic that might otherwise prevent direct execution attempts. Once stored, this template is not immediately executed but remains dormant within the system's data storage until triggered by another action. The second phase involves invoking MockController::infoByKey, which retrieves and processes the previously stored template. During this processing stage, the application passes the content of the mockjs template directly to an eval() function without adequate sanitization or context-aware parsing.
This direct invocation of eval() on user-controlled input constitutes a severe security failure classified under CWE-94 Improper Control of Generation of Code (Code Injection). By leveraging escaped parentheses in the stored payload, attackers can manipulate the evaluation context to execute arbitrary shell commands rather than merely generating mock data. The severity of this vulnerability is significantly amplified by its potential impact on system integrity and availability. In environments where ShowDoc is deployed using the official Docker image, the application often runs with elevated privileges, potentially as the root user. Consequently successful exploitation allows an attacker to gain full control over the underlying host operating system, effectively compromising not just the web application but the entire server infrastructure it resides upon.
From a threat intelligence perspective this vulnerability aligns with ATT&CK techniques related to Command and Scripting Interpreter abuse, specifically T1059 which covers execution via various scripting languages including JavaScript through eval() calls. The attack pattern reflects common exploitation strategies where attackers first establish persistence or storage of malicious artifacts before triggering them in contexts that allow for higher privilege escalation. This two-stage approach makes detection more challenging as the initial upload may appear benign until the specific trigger condition is met during normal application usage patterns.
Mitigation efforts must prioritize immediate patching to version 3.9.6 or later where these input validation and output encoding issues have been addressed by the development team. Organizations running older versions should restrict access to the Mock feature if possible, ensuring that only trusted administrators can create or modify mock templates. Additionally implementing strict web application firewall rules that detect patterns associated with eval() exploitation and escaped parenthesis sequences in POST requests targeting mock-related endpoints can provide a layer of defense-in-depth while patching is underway. Regular audits of authenticated user activities within the Mock module are also recommended to identify any unauthorized template injections before they lead to full system compromise.