Malicious activity targeting a critical severity flaw in the ‘Better Search Replace’ WordPress plugin has been detected, with researchers observing thousands of attempts in the past 24 hours.
Better Search Replace is a WordPress plugin with more than one million installations that helps with search and replace operations in databases when moving websites to new domains or servers.
Admins can use it to search and replace specific text in the database or handle serialized data, and it provides selective replacement options, support for WordPress Multisite, and also includes a “dry run” option to make sure that everything works fine.
The plugin vendor, WP Engine, released version 1.4.5 last week to address a critical-severity PHP object injection vulnerability tracked as CVE-2023-6933.
The security issue stems from deserializing untrusted input and allows unauthenticated attackers to inject a PHP object. Successful exploitation could lead to code execution, access to sensitive data, file manipulation or deletion, and triggering an infinite loop denial of service condition.
The description of the flaw in Wordfence’s tracker states that Better Search Replace isn’t directly vulnerable but can be exploited to execute code, retrieve sensitive data, or delete files if another plugin or theme on the same site contains the Property Oriented Programming (POP) chain.
The exploitability of PHP object injection vulnerabilities often relies on the presence of a suitable POP chain that can be triggered by the injected object to perform malicious actions.
Hackers have seized the opportunity to exploit the vulnerability as WordPress security firm Wordfence reports that it has blocked over 2,500 attacks targeting CVE-2023-6933 on its clients over the past 24 hours.
The flaw impacts all Better Search Replace versions up to 1.4.4. Users are strongly recommended to upgrade to 1.4.5 as soon as possible.
Download stats on WordPress.org recorded close to a half million downloads over the past week, with 81% of the active versions being 1.4 but unclear about the minor release.
Update 1/25 - Wordfence has told BleepingComputer that they initially used a broad rule to detect the activity described above, and as a result, some of the logged attempts concern other flaws, like CVE-2023-25135. However, most of the attacks are attributed to exploitation attempts for CVE-2023-6933.
Comments
PluginVulns - 1 month ago
Wordfence is now saying there haven’t been any exploit attempts in the last 24 hours.
Wordfence’s information on this looks to be misleading. The developer’s changelog states that exploiting this would occur “during search and replace operations” when there is “malicious code stored in the database.” The update that is supposed to address this doesn’t change what is required to access any functionality, only stopping instantiating objects when unserializing. So it looks like either this would require high-level user action before exploitation could possibly happen or there is another problem that hasn’t been addressed. Wordfence providing more information would be helpful to figure out if there is a further problem or if they are leaving an important limitation out of their description.
Based on that, it seems like Wordfence’s firewall rule might be blocking general PHP object input instead of an attack against this specific issue. Certainly it wouldn’t be detecting otherwise successful exploitation of this, because that would require another step.
Getting clarification from Wordfence would be helpful, because right now it seems possible the main claim of the story that hackers are attacking this might be wrong.
PluginVulns - 1 month ago
Based on the update to the story about Wordfence narrowing their rule and the continued lack of them claiming to be stopping any more attacks, it seems like they were probably blocking general PHP object injection input instead.
A good question is why they would stop blocking that. Other WordPress security plugins, including ours, safely provide broader protection against PHP object injection and don't require writing rules for specific vulnerabilities like Wordfence does. That leads to broader protection, including being able to offer zero-day protection against that type of vulnerability.