Last month, security provider Tenable claimed that an authenticated SQL injection vulnerability had existed in the WordPress plugin ReviewX and was fixed in version 1.6.4. It turns out the vulnerability hasn’t been fixed.
The CVE system allowed Tenable to create a CVE ID for this, CVE-2023-26325, and didn’t check to make sure the claims were accurate [Read more]
It’s a bad look when a major WordPress security provider is disclosing that one of their own plugins has a serious security issue, which happened six months ago with the developer of iThemes Security. It’s even worse when the code is so insecure, which was also the case with iThemes. Automattic, the company of the head of WordPress Matt Mullenweg, which provides security solutions under brands including WPScan and Jetpack, today fixed a serious vulnerability in one of their plugins. That this happened runs counter to the view we see often that Automattic are security experts, but in line with previous security issues with their software. Unlike the situation with iThemes, though, this isn’t known to be a zero-day (a vulnerability being exploited before the developer knows about it) and doesn’t involve a security failure at such a basic level. It does involve having incredibly insecure code running in a situation that is high risk.
With that said, this situation could be used as impetus to finally move WordPress plugin security to a better place. But first, let’s look at what went wrong here. [Read more]
Recently Automattic’s Jetpack claimed to have done an “internal audit” of the WordPress plugin Slimstat Analytics and found an authenticated SQL injection vulnerability that was subsequently fixed. We don’t know what an internal audit is supposed to be, but they failed to fully test or check over the vulnerable code and the authenticated SQL injection vulnerability still exists (which isn’t that surprising, considering the discoverer is a former employee of Sucuri). They also missed another security issue in the relevant code, which helped lead to the vulnerability still existing. Interestingly, an in development feature of our firewall plugin caught that the issue hadn’t been fully resolved.
Another Automattic unit, WPScan, also missed that this wasn’t fully resolved: [Read more]
Automattic’s WPScan WordPress security service makes a lot of impressive sounding claims on their homepage, including being “Enterprise-strength” protection:
Enterprise-strength WordPress protection for everyone [Read more]
Anyone who has spent much time trying to use WordPress’ support forum and the connected plugin review system knows that the moderators of that often get in the way and causing unnecessary problems (as well other troubling behavior, including deleting unflattering information about a company they promote). At the same time, they don’t take action when there is something they could help with. That is the case involving the 8,000+ install WordPress plugin Bulk Delete Comments. Two weeks ago, a one-star review was left with a concerning claim:
This plugin might be hacked or it is shady on way or another because it have started to slow down wordpress when including a an inclusion of javascript located at: alishahalom.com [Read more]
Trust is an important part of security, so it probably isn’t surprising that security is in such bad shape and that at the same time, security companies are so obviously dishonest so often. That is something we frequently run across in the WordPress security space, involving even the big name players. A couple of instances of that just came up involving vulnerability data provider presenting it as if they added information on vulnerabilities in a more timely manner than they really do.
Automattic’s WPScan is claiming there is a known vulnerability in the latest version of WordPress. Though this would probably be better classified as a security issue. WPScan’s data says that the issue was “publicly published” and “added” two days ago: [Read more]
In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use, we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports, we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular, are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to the level of getting their own post, we now place them in a weekly post when we come across them.
Automattic’s WPScan claimed an admin+ blind SSRF vulnerability had existed in Post SMTP. The description doesn’t make sense: [Read more]
During the summer, one arm of the company closely associated with WordPress, Automattic, WPScan disclosed a vulnerability in plugin, Co-Authors Plus, maintained by another arm of Automattic. WPScan and others in Automattic appear to have failed to look all that closely at the issue, as the plugin still has a closely related vulnerability.
According to the documentation for the plugin, it is maintained by WordPress VIP: [Read more]
A reoccurring issue we see with information on vulnerabilities in WordPress plugins is that inaccurate information is being provided to webmaster’s and then the sources of that inaccurate information are not the ones having to deal with the fallout of that. Take this recent forum topic for the plugin Advanced Contact Form 7 DB (Advanced CF7 DB) , which included a message coming from the paid iThemes Security Pro service claiming that there was a “known” vulnerability in the latest version of the plugin, version 1.9.1. Here is the message:
SEPT 30: Known issues in Advanced Contact form 7 DB v1.9.1 [Read more]
In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use, we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports, we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular, are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to the level of getting their own post, we now place them in a weekly post when we come across them.
Automattic’s WPScan claimed there was an admin+ PHP objection injection vulnerability in Ninja Forms. Presumably they were trying to refer to “PHP object injection”. They explained it this way: [Read more]