CVE-2026-88997 in JSM Show Post Metadata Plugin
Summary
by MITRE • 09/23/2026
The JSM Show Post Metadata WordPress plugin before 4.9.1 does not properly escape a post meta key before outputting it into an inline event-handler attribute in an admin-facing meta box, allowing users with contributor-level access and above to inject arbitrary JavaScript that executes in the session of a higher-privileged user who reviews the affected post.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in JSM Show Post Metadata WordPress plugin versions prior to 4.9.1 represents a critical security flaw rooted in improper input validation and output encoding within an administrative interface component. Specifically, the defect lies in how the plugin handles user-supplied data for post meta keys when rendering them into HTML attributes associated with inline event handlers. In web application architecture, particularly within content management systems like WordPress, admin-facing pages are intended to be accessible only by authenticated users with elevated privileges such as administrators or editors who manage site content and configuration. However, this implementation flaw allows the injection of malicious script payloads through a mechanism known as stored cross-site scripting, where the malicious code is permanently stored on the target server within the application's database via the post meta key field.
From a technical perspective, the core issue involves the failure to properly escape or encode special characters in the post meta key before it is embedded into an inline event-handler attribute, such as onclick or onchange, within the HTML markup of a meta box. When a user with contributor-level access or higher creates or edits a post, they can supply arbitrary values for these metadata fields. Because the application does not sanitize this input against script injection vectors, any JavaScript code included in the key is rendered directly into the browser's DOM without transformation. This lack of context-aware output encoding means that when an administrator later views or reviews the affected post within the WordPress dashboard, their browser interprets the injected content as executable scripts rather than plain text data.
The operational impact of this vulnerability is significant due to its potential for privilege escalation and session hijacking. Since the malicious script executes in the context of a higher-privileged user's active session, an attacker with lower-level access can effectively impersonate that administrator. This enables the extraction of sensitive administrative cookies, including authentication tokens, which could allow the attacker to take full control of the WordPress installation. Furthermore, the injected code can perform actions on behalf of the admin, such as modifying site settings, creating new user accounts with elevated privileges, or defacing public-facing pages if the script includes logic for cross-site request forgery attacks against other administrative endpoints. The persistence of this threat means that every time an administrator accesses a post containing the malicious metadata, their session is compromised until they clear their browser cache and cookies or remove the tainted content from the database.
This vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation as Cross-site Scripting (XSS). More specifically, it falls under Stored XSS because the malicious payload is saved in the application's data store rather than being passed via a single HTTP request parameter that disappears after execution. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1059, which covers Command and Scripting Interpretation, specifically within the context of web applications where JavaScript serves as the scripting language for exploitation. The attack vector leverages social engineering elements indirectly by relying on trusted administrators interacting with compromised content, fitting into broader tactics related to Initial Access or Privilege Escalation depending on the ultimate goal of the attacker.
Mitigation strategies must focus primarily on immediate patching and rigorous input validation practices. Administrators running affected versions should upgrade the JSM Show Post Metadata plugin to version 4.9.1 or later, where this specific encoding flaw has been addressed by developers implementing proper output escaping functions such as esc_attr in WordPress development standards. For organizations unable to update immediately due to compatibility constraints, temporary workarounds include restricting contributor-level access to only trusted individuals and manually auditing post metadata for suspicious script tags before publication. Additionally, implementing a Content Security Policy (CSP) header can help mitigate the impact of any successful injection by restricting the sources from which scripts are allowed to execute, thereby preventing inline event handlers from running untrusted code even if they are present in the DOM. Long-term resilience requires adopting secure coding guidelines that mandate context-sensitive encoding for all dynamic data rendered into HTML attributes and regular security audits of third-party plugins used within critical infrastructure environments.