CVE-2026-120114 in Debug Log Manager Plugin
Summary
by MITRE • 10/31/2026
The Debug Log Manager – Conveniently Monitor and Inspect Errors plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'message (and pageUrl)' parameter in all versions up to, and including, 2.5.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Successful exploitation requires that the site administrator has debug logging enabled with JS error logging active, and that the attacker can obtain the publicly emitted dlmVars.jsErrorLogging nonce — which is broadcast on every frontend page — to pass the nonce check on the unauthenticated endpoint.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
The Debug Log Manager plugin for WordPress presents a significant security risk due to a stored cross-site scripting vulnerability affecting all versions up to and including 2.5.2. This flaw stems from insufficient input sanitization and output escaping mechanisms within the application code, specifically targeting the message and pageUrl parameters used in log entries. The nature of this vulnerability allows attackers to inject arbitrary web scripts into pages that are subsequently viewed by other users, leading to potential compromise of user sessions or data theft when those scripts execute in a victim's browser context.
Successful exploitation of this vulnerability relies on specific environmental conditions within the target WordPress installation. First, the site administrator must have debug logging enabled with JavaScript error logging actively configured. Second, and critically, an unauthenticated attacker must be able to obtain the dlmVars.jsErrorLogging nonce value. This nonce is broadcast publicly on every frontend page of the website, making it readily accessible without any authentication requirements. Once obtained, this nonce allows the attacker to bypass security checks associated with the unauthenticated endpoint responsible for processing log entries, thereby enabling the injection of malicious content into the debug logs.
The operational impact of this vulnerability extends beyond simple script execution. Because the injected scripts are stored within the application's logging system, they persist until manually removed or overwritten by legitimate log entries. This persistence means that any user who accesses a page where an error occurred and triggered the logging mechanism may inadvertently execute the malicious code. The consequences can include session hijacking, defacement of the website interface, redirection to phishing sites, or installation of additional malware on the victim's device. Given that debug logs are often accessed by administrators for troubleshooting purposes, these users become high-value targets due to their elevated privileges within the WordPress environment.
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. The attack vector leverages stored persistence mechanisms typical of persistent XSS attacks, where malicious content is saved on the target server and served to multiple victims over time. In terms of adversary tactics, this aligns with MITRE ATT&CK techniques related to Client-side Injection and potentially Initial Access if used in conjunction with social engineering or other vectors to trigger specific error conditions that result in log entry creation.
Mitigation strategies should prioritize immediate remediation through software updates. Administrators running affected versions must upgrade the Debug Log Manager plugin to a version newer than 2.5.2, where these input sanitization and output escaping issues have been addressed by the developers. Until an update is applied, administrators can consider disabling JavaScript error logging if it is not strictly necessary for their operational needs, thereby removing the attack vector that relies on capturing JS errors. Additionally, reviewing server-side configurations to limit access to debug logs or implementing Web Application Firewall rules that detect and block XSS payloads in log inputs may provide temporary protection against exploitation attempts while permanent fixes are deployed.