CVE-2026-85683 in Jane Menu Plugin
Summary
by MITRE • 10/22/2026
The Jane Menu WordPress plugin before 1.5.1 does not have any capability or nonce checks on one of its form handlers, which is reachable by unauthenticated users, allowing them to bind any published page to a remote document of their choosing. The plugin then fetches that document and outputs its head and body into the page without escaping, so an unauthenticated attacker can run arbitrary JavaScript in the browser of any visitor to that page, including an administrator.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The Jane Menu WordPress plugin version 1.5.0 and earlier contains a critical server-side request forgery vulnerability combined with cross-site scripting due to insufficient input validation and output encoding on its form handling endpoints. This security flaw stems from the absence of capability checks, which verify user permissions, and nonce verification, which ensures that requests originate from legitimate forms submitted by authenticated users within an expected timeframe. Because these protective mechanisms are missing, any unauthenticated actor can interact directly with the plugin's API endpoint without needing valid credentials or session tokens. This lack of access control allows external entities to trigger server-side operations intended only for authorized administrators or editors, fundamentally breaking the trust model of the WordPress application environment.
The technical exploitation involves an attacker crafting a malicious request that specifies a remote document URL as input to the vulnerable form handler. Upon receiving this request, the plugin fetches the content from the specified external source and injects it directly into the response body without performing any sanitization or encoding operations. This behavior creates a classic reflected cross-site scripting scenario where arbitrary HTML and JavaScript code embedded in the fetched remote document are rendered by the victim's browser as part of the legitimate page structure. Since the output is not escaped, the browser interprets script tags within the injected content as executable commands rather than static text data.
The operational impact of this vulnerability is severe because it enables unauthenticated attackers to execute arbitrary JavaScript in the context of any visitor viewing the affected page. This includes high-privilege users such as site administrators who may browse the public-facing pages while managing the website. Successful exploitation allows for session hijacking, where attacker-controlled scripts can steal authentication cookies and tokens to impersonate legitimate users. It also facilitates credential theft through fake login forms or keylogging mechanisms embedded in the injected script. Furthermore, attackers can perform actions on behalf of authenticated users, such as modifying site settings, creating new administrative accounts, or defacing the website content by altering DOM elements dynamically after page load.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-79 Cross-site Scripting due to the injection of executable code via unsanitized input. In terms of attack vectors, it corresponds to ATT&CK technique T1059 Command and Scripting Interpreter for executing malicious scripts and T1078 Valid Accounts if session tokens are stolen to escalate privileges or perform further actions within the compromised WordPress installation. The lack of nonce verification also relates to CWE-352 Cross-Site Request Forgery, as the application fails to verify that requests were intentionally initiated by legitimate users.
Mitigation strategies require immediate updates to version 1.5.1 or later where these security controls have been implemented. Administrators should ensure that all form handlers enforce strict capability checks to restrict access based on user roles and implement nonce verification to prevent unauthorized request submission. From a defensive coding perspective, developers must apply output encoding functions such as esc_html or wp_kses_post when rendering dynamic content to neutralize any potentially malicious scripts before they reach the browser. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact even if a similar vulnerability exists in other plugins.