CVE-2026-114422 in Enable Media Replace Plugin
Summary
by MITRE • 10/30/2026
The Enable Media Replace WordPress plugin before 4.2.3 does not restrict the classes allowed when deserializing stored metadata during its media replace-and-update-links routine, allowing unauthenticated users to inject a PHP object that is instantiated when a user with upload access performs a routine media replacement, resulting in PHP Object Injection and local file inclusion of existing PHP/HTML files, which can be escalated to remote code execution where an attacker-influenced PHP or HTML file is present on the server. This is a regression of CVE-2023-4643, which was fixed in 4.1.3 and reintroduced in 4.1.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The Enable Media Replace WordPress plugin version 4.2.3 and earlier contains a critical security vulnerability rooted in improper handling of serialized data during the media replacement workflow. This flaw specifically affects the deserialization process used to store metadata when users replace existing media files or update associated links within the WordPress environment. The core technical deficiency lies in the failure to restrict the PHP classes that are permitted for instantiation during this unserialization operation. By not implementing a strict allowlist of safe classes, the application inadvertently accepts arbitrary class names from user-controlled input, creating an opening for attackers to manipulate the deserialization logic. This architectural oversight allows any authenticated user with upload privileges to craft malicious payloads that exploit the PHP object injection mechanism inherent in WordPress's handling of serialized metadata.
This vulnerability is classified as a regression of CVE-2023-4643, which was previously addressed in version 4.1.3 but was inadvertently reintroduced in subsequent releases starting with version 4.1.4. The persistence of this flaw highlights the challenges associated with maintaining security patches across iterative software updates and underscores the importance of rigorous regression testing for vulnerability fixes. The attack vector requires an unauthenticated user to first gain authenticated access as a contributor or higher, leveraging standard WordPress capabilities such as media upload permissions. Once inside this boundary, the attacker can inject a specially crafted PHP object into the metadata field associated with a media file. When another administrator or editor performs a routine action that triggers the deserialization of this stored metadata, typically during a media replacement operation, the malicious object is instantiated by the application server.
The operational impact of this vulnerability extends beyond simple data corruption due to its potential for remote code execution under specific conditions. While PHP Object Injection itself provides significant control over application behavior, it can be chained with other vulnerabilities or configurations to achieve more severe outcomes. If an attacker has previously uploaded a malicious PHP script disguised as HTML or another file type to the server's upload directory, the object injection vulnerability allows them to trigger local file inclusion of that payload. This chain effectively escalates the threat from arbitrary code execution within the context of the WordPress process to full remote code execution on the underlying web server. Such escalation grants attackers complete control over the compromised system, enabling data exfiltration, further lateral movement within the network, and persistent backdoor installation.
From a classification perspective, this vulnerability aligns with CWE-502, which denotes Deserialization of Untrusted Data, as well as CWE-94, representing Code Injection via improper neutralization of special elements in code. In terms of offensive security frameworks like MITRE ATT&CK, the exploitation path corresponds to techniques involving T1059 Command and Scripting Interpreter for executing arbitrary commands and potentially T1505 Server Software Component for leveraging installed software components as a persistence mechanism if file inclusion is successfully achieved. The vulnerability emphasizes the risk associated with legacy PHP practices that rely on automatic class loading during deserialization without adequate validation of object types.
Mitigation strategies must prioritize immediate patching to version 4.2.3 or later, where these restrictions have been properly re-implemented. Administrators should also enforce strict file upload permissions and disable unnecessary capabilities for lower-privileged user roles to limit the attack surface available to potential intruders. Additionally, implementing server-side controls such as disabling PHP object deserialization entirely if not required by other plugins can provide a robust defense-in-depth measure. Regular security audits and dependency management practices are essential to prevent similar regressions in future updates, ensuring that fixes for critical vulnerabilities like CVE-2023-4643 remain effective across all released versions of the software ecosystem.