CVE-2026-97020 in dougwollison
Summary
by MITRE • 10/14/2026
The PO/MO Editor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'podata' parameter in all versions up to, and including, 1.4.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The injected payload is loaded as a replacement .po/.mo translation file via the plugin's own load_textdomain_mofile filter, causing WordPress to serve the attacker-written translation in place of the original core strings.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The PO/MO Editor plugin for WordPress contains a critical security vulnerability affecting all versions up to and including 1.4.2. This flaw is classified as a Stored Cross-Site Scripting (XSS) issue, specifically identified under CWE-79 in the Common Weakness Enumeration standard. The root cause of this vulnerability lies in insufficient input sanitization and output escaping mechanisms within the plugin's handling of the podata parameter. Unlike reflected XSS attacks where malicious scripts are executed immediately via a crafted link, stored vulnerabilities persist on the target server, making them particularly dangerous as they affect every user who views the compromised content. The attack vector requires authenticated access, but notably, it can be exploited by users with subscriber-level privileges or higher. This low barrier to entry significantly increases the risk surface, as even basic accounts on a WordPress installation possess sufficient permissions to trigger this flaw.
The technical mechanism of exploitation involves injecting arbitrary web scripts through the podata parameter. The plugin utilizes its own load_textdomain_mofile filter to process translation files in .po and .mo formats. An attacker can craft a malicious payload disguised as or injected into these translation file structures. When WordPress processes this data, it fails to properly validate or escape the content before rendering it within the application context. Consequently, when an administrator or another user accesses a page containing the compromised post or configuration, the browser interprets the injected code as legitimate script execution rather than static text. This allows the attacker's JavaScript to run with the same privileges and context as the rest of the web application, effectively bypassing standard security controls that rely on input validation at higher privilege levels only.
The operational impact of this vulnerability is severe due to its stored nature. Once the malicious payload is injected, it remains active until manually removed from the database or plugin settings. This persistence means that every subsequent visit by any user with access rights can result in script execution. Attackers typically leverage such vulnerabilities for session hijacking, where they steal authentication cookies to impersonate legitimate users and escalate privileges. Additionally, stored XSS can be used to deface websites, redirect traffic to phishing sites, or deploy further malware onto the visitor's machine through drive-by downloads. The ability to execute arbitrary code in the context of an authenticated user undermines the integrity and confidentiality of the entire WordPress environment, potentially leading to full site compromise if combined with other vulnerabilities or misconfigurations.
Mitigation strategies must address both immediate remediation and long-term security hygiene. The primary recommendation is to update the PO/MO Editor plugin to a version newer than 1.4.2 immediately upon availability from the official repository, as this patch resolves the input sanitization flaws. For sites unable to upgrade instantly due to compatibility concerns, temporary mitigations include restricting user roles that can access the translation editor features or disabling the specific functionality if not required for operations. Implementing a Web Application Firewall (WAF) with rules tuned to detect and block XSS payloads in POST requests targeting this parameter can provide an additional layer of defense. Furthermore, organizations should enforce strict Content Security Policy headers to mitigate the impact of any successful injection by restricting script execution sources. Regular security audits and code reviews focusing on input validation and output escaping practices are essential to prevent similar vulnerabilities from being introduced or persisting within custom plugins and themes aligned with ATT&CK techniques related to client-side evasion and persistence mechanisms.