Yesterday, the Bleeping Computer ran a story headlined “Hackers target WordPress database plugin active on 1 million sites,” written by Bill Toulas. The plugin being referenced was Better Search Replace, which had a security change in the latest version. There doesn’t appear to have been a hacker targeting it, though.

The only thing backing up that headline was described this way:

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.

CVE-2023-6933 is a reference to the security issue (and possible vulnerability) fixed in Better Search Replace.

That seems like a rather small number of attacks to have stopped if a hacker was trying to exploit something in a plugin with a million installs. By shortly after the post was published, Wordfence had stopped claiming to have stopped anymore attacks against this. That has continued to be true today. That seems odd.

The story was later updated yesterday, with this note:

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.

Considering that Wordfence stopped reporting blocking any attacks, it would seem to suggest they were actually stopping attempts to exploit other things with the original rule.

In a comment we left on the post before that update, we wrote it seemed “like Wordfence’s firewall rule might be blocking general PHP object input instead of an attack against this specific issue.” That appears to have been correct.

Where things get even more problematic, is what else we noted:

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.

It’s unclear if this would be exploitable, but unless there is another issue that hasn’t been addressed, this seems like a relatively minor issue. That isn’t how the story and Wordfence presented it. The story refers to it as being a critical vulnerability twice. That might be a reference to a severity score that Wordfence put forward:

What the story lacked was a second source. If someone other than Wordfence had been contacted, they could have explained to the developer what we then mentioned in our comment. Instead, you get a story that seems to have been false in its main thrust.

A good follow up question on this is why Wordfence stopped blocking attacks more generally. Other WordPress security plugins, including our own, 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.