CVE-2026-5714: Enable Media Replace WordPress Plugin Stored XSS Vulnerability

Technical summary

Enable Media Replace is vulnerable to Stored XSS (CWE-79) via the 'location_dir' parameter. The plugin does not adequately sanitize user input before storage or escape output when rendering the parameter in the page context. This allows authenticated attackers with Author-level access or above to store arbitrary JavaScript payloads that execute in the context of other users' browsers when they access affected pages. The vulnerability is stored rather than reflected, meaning the malicious payload persists in the WordPress database until manually removed, affecting all subsequent visitors.

Business impact

This vulnerability primarily affects multi-author WordPress installations where not all content creators can be fully trusted or where account compromise is a risk. An attacker exploiting this flaw could steal admin session cookies, redirect users to malicious sites, deface content, inject spam or malware links, or perform administrative actions. For organizations using Enable Media Replace to manage media assets across teams, the risk scales with the number of authors and the sensitivity of the WordPress installation. Recovery requires identifying and removing injected content, resetting compromised sessions, and auditing user permissions.

Affected systems

All versions of the Enable Media Replace WordPress plugin up to and including version 4.1.8 are affected. The vulnerability requires that an attacker possess Author-level access or higher within the WordPress installation, meaning it does not affect sites where contributor and author access is tightly restricted. Any WordPress site actively running this plugin with multiple authors or untrusted user roles should be considered at risk.

Exploitability

Exploitation requires valid WordPress credentials with at least Author-level access, making this an insider threat or account compromise scenario. The attack is trivial to execute once access is obtained—simply modifying the 'location_dir' parameter with JavaScript payloads. No user interaction is required beyond the attacker's initial action; the payload executes automatically when others visit the affected page. The attack surface is limited to organizations that grant Author access to multiple users or have experienced account compromise.

Remediation

Update the Enable Media Replace plugin to a patched version released after 4.1.8 (verify the version number against the official plugin repository or vendor advisory). In the interim, restrict Author-level access to trusted users only, implement Web Application Firewall (WAF) rules to detect script injection patterns in the location_dir parameter, and audit the plugin's database tables for suspicious content that may have been injected. Consider temporarily disabling the plugin if it is not actively required.

Patch guidance

Check the official Enable Media Replace plugin repository on WordPress.org for the latest available version. Apply updates through the WordPress admin dashboard or via command line tools. Verify that the patched version explicitly addresses input sanitization and output escaping of the 'location_dir' parameter. After patching, test media replacement functionality to ensure no regressions. For high-risk environments, consider testing patches in a staging environment before production deployment.

Detection guidance

Monitor WordPress database queries and file uploads to the media directory for unusual patterns or timing correlation with suspicious author activity. Search database records and post meta for encoded or obfuscated JavaScript in the location_dir parameter or related media metadata. Review WordPress activity logs (if available via security plugins) to identify Author-level users creating or modifying pages around suspected injection timeframes. Inspect HTTP requests to the plugin's endpoints for script-like syntax in the location_dir parameter. Consider using security plugins that detect Stored XSS patterns in WordPress content.

Why prioritize this

While this is a Stored XSS vulnerability with a CVSS score of 6.4 (MEDIUM), prioritization depends on your environment. Organizations with multi-author WordPress installations, especially those managing sensitive content or user data, should treat this as high priority. Single-admin sites or those with restricted author access can deprioritize, but should still plan patching as part of routine maintenance. The persistent nature of stored XSS and potential for privilege escalation or lateral movement make it more severe than typical reflected XSS.

Risk score, explained

The CVSS 3.1 score of 6.4 reflects a vulnerability requiring authentication (PR:L), no user interaction (UI:N), network-based attack vector (AV:N), and low complexity (AC:L). The impact is limited in scope (C:L, I:L, A:N), meaning confidentiality and integrity are minimally affected and there is no availability impact. The score does not fully account for the persistent nature of stored XSS or organizational context; sites with high-value content or multiple authors should weight this higher internally.

Frequently asked questions