Yesterday, data we track showed that what was likely a hacker was probing for usage of the 100,000+ install WordPress plugin TI WooCommerce Wishlist, by requesting its readme.txt file. Why would a hacker be interested in the plugin? Presumably there shouldn’t be any publicly known unfixed vulnerabilities, as the plugin hasn’t been closed in the WordPress plugin directory:
Back in September, the developer of the 2+ million WordPress plugin MC4WP: Mailchimp for WordPress and Wordfence claimed that a minor vulnerability had been fixed. The fix was obviously incomplete and it turns out the issue is wider than that.
…
Today, we have had two requests on our website checking if we were using a WordPress plugin by checking for the readme.txt file for it. The requests were for the path /wp-content/plugins/baiduseo/readme.txt. Those appeared to come from a hacker. Why would that be? Well the plugin, SEO合集(支持百度/Google/Bing/头条推送), was closed on the WordPress plugin directory yesterday:
During the weekend an apparent hacker made multiple requests on our website for a file that would be located at /wp-content/plugins/google-listings-and-ads/vendor/googleads/google-ads-php/scripts/print_php_information.php. That would be a file that would be part of the Google for WooCommerce, which is developed by the company from the head of WordPress, Automattic. That file turned out to be in two other plugins, one of which is still vulnerable and still in the WordPress Plugin Directory. Something that WordPress and other WordPress security providers have missed. It also is still in the library from Google that it is originally from.
The file doesn’t exist in the current version of Google for WooCommerce. It was removed from the plugin in version 2.8.7, which was released on November 14. In the changelog, that change was described as “Fix – Remove a Google Ads API vendor file that prints php information.” The contents of the file before that were: [Read more]
On Tuesday we had what appeared to be a hacker sending multiple requests to our website attempting to access code that we found was in a WordPress plugin with 100,000+ installs, Relevanssi. (We don’t use the plugin.) Looking at the code, we found that the related code was not secure in the latest version of the plugin. Several steps later, we found that it was supposed to have been secured over a year ago, but wasn’t. That involved a claimed security researcher and another WordPress security provider, both of which don’t provide the needed information to vet their claims and make sure things actually get fixed (or make sure they are actually vulnerabilities). This is a reoccurring problem and to help warn about that, we are now compiling a database of claimed WordPress security researchers with warnings if they are causing problems like that (or a notice that they are a reliable source, for the few that are). After doing work we shouldn’t have had to do, we were able to work with the developer of the plugin to get the problem properly addressed.
Getting back to the code being targeted, in the plugin’s file /lib/init.php, the plugin has the function relevanssi_export_log_check() run after active plugins have been loaded while WordPress is generating a page: [Read more]
Other WordPress security providers have been provided inaccurate information of the scope of a vulnerability in the WordPress plugin Login Lockdown. Here is how Wordfence explained it:
…
One of the reasons why WordPress plugins continue to be so insecure is that unethical security providers don’t do basic vetting work before claiming that vulnerabilities exist and that they have been fixed. Unsurprisingly, they don’t show the work, as it were, as to how they came to claim there was a vulnerability. That often leads to real security issues and vulnerabilities remaining in plugins after they take credit for them being fixed. That was the case recently with a situation that involved one of those unethical providers, Wordfence, and WordPress.
Last week, our monitoring systems flag the possibility of a vulnerability in the plugin WPMasterToolKit. At the time, the plugin was closed on the WordPress Plugin Directory. The reason for the closure appears to be a claim by Wordfence of a vulnerability in the plugin. The author of the plugin stated: [Read more]
In January, the developers of the 4+ million install WordPress plugin Really Simple Security vaguely disclosed they had attempted to fix a vulnerability in the plugin. That was done through one of the changelog entries for version 9.2.0, “Fix: Added nonce check to certificate re-check button.” That is a reference to addressing a cross-site request forgery (CSRF) vulnerability. Checking on that months later, we found that the fix had been incomplete and that competing vulnerability data sources had failed to properly vet this and claimed that the issue was fully addressed. That includes the data source used by Really Simple Security, so their own users have not been warned the plugin is still vulnerable.
Looking at the changes made in that version, the changelog references a change made in the file /class-admin.php. That file is run during admin_init, which makes it accessible to anyone: [Read more]
Last week, once again, supposed security journalists and security provider Patchstack were spreading misinformation about a vulnerability in a WordPress plugin. They claimed a vulnerability had been exploited hours after it was disclosed. In reality, there were exploit attempts, but no evidence of any exploitation. And that actually happened a day or a week after the vulnerability was disclosed, depending on what you consider as disclosure.
That a plugin from the developer of the plugin had a vulnerability that would receive interest from hackers isn’t a surprise, as it is a developer that has a long track record of poor handling of security. We recommended not using their plugins in January 2024, unless they could show they had gotten a better handle on security. As we noted in January of this year, they clearly hadn’t gotten a better handle on things by then. With this vulnerability, they did fix it the same day they were informed of it. Unfortunately, the vulnerability was fixed weeks after it should have been, as the notification happened weeks after it should have been. That was because an unethical security provider paid the discoverer to not report it to the developer. [Read more]
Across various data we monitor we have been seeing what looks to be a hacker or hackers trying to find websites using the plugin Kubio Pro, by requesting this url: /wp-content/plugins/kubio-pro/readme.txt. At first we were puzzled as to what might explain that. There isn’t a plugin on the WordPress Plugin Directory with the slug kubio-pro, so that would mean either it likely was a plugin made available somewhere else or a backdoor disguised as a plugin. We looked for any information on the web about a vulnerability in a plugin with that slug or the name Kubio Pro and came up with nothing. The same is true for competing data sources for information on vulnerabilities in WordPress plugins.
WPScan, owned by Automattic, serves a not found page for the URL that would contain data on vulnerabilities for a plugin with that slug: [Read more]
