Does Search Regex Plugin Vulnerability Permit Code Execution?

The short version

• The Search Regex plugin contains a PHP object injection flaw.
• Attackers need only subscriber-level access to trigger the issue.
• Code execution is possible through a POP chain exploit.

The details

The Search Regex plugin for WordPress, developed by johnny5, is vulnerable to PHP object injection in version 3.5. According to the NVD record, the flaw exists within the replace_all function, which deserialises untrusted input. This specific weakness, categorised under CWE-502, allows an attacker to inject a PHP object into the application. The presence of a PHP Object Injection (POP) chain means that injecting the object is not the end goal; it serves as a pathway to execute arbitrary code on the server. This significantly elevates the risk from a mere data manipulation issue to a full system compromise scenario.

The context

This vulnerability carries a CVSS score of 8, which is rated as high severity by the NVD. The attack requires authentication, but the threshold is low: any user with subscriber-level access or higher can exploit it. This broadens the potential attack surface considerably, as subscriber accounts are common in multi-author WordPress environments. Unlike issues requiring administrative privileges, this flaw exposes the site to a much wider range of potential adversaries who may have obtained low-level credentials.

Next steps

Site administrators should immediately audit their WordPress installations for the Search Regex plugin. Those running version 3.5 or earlier are exposed to this risk. As no patch has been confirmed in the source material, teams should consider disabling the plugin if it is not essential to their operations. Monitoring for unusual activity is critical until a vendor update becomes available. Reviewing user permissions to limit subscriber access where possible may also reduce the immediate attack surface.

What defenders should look for

Teams usually monitor for anomalous PHP execution patterns originating from lower-privileged accounts. Check whether logged-in users with minimal permissions are triggering complex database queries or file operations. Look for signs of object deserialization, such as unexpected base64-encoded payloads in request parameters. First containment moves often involve isolating affected web servers and revoking suspicious user sessions. Verify that logging captures detailed input data to identify the specific injection vector used by the attacker.

What to do and how to stay safe

• Audit all WordPress sites for the Search Regex plugin and identify versions 3.5 or lower.
• Review user accounts with subscriber-level access to ensure no compromised credentials exist.
• Monitor web server logs for unusual POST requests to the replace_all function endpoint.
• Isolate vulnerable instances from the network until a vendor-provided update is verified.

Step-by-step guide: How Virtual Patching Works: The Mechanics Behind Inline Protection

General security guidance from the Honeypot Daily newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which version of the Search Regex plugin is affected?

Version 3.5 and earlier versions of the plugin are vulnerable to this flaw.