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.
…
On Friday, WPMU DEV partially released a security update for the WordPress plugin Broken Link Checker. The changelog for the new version is “Fix: Patched a vulnerability issue.” There are a couple of problems with that. First, they didn’t set it, so the update is being offered to those already using the plugin or new users. Second, the fix was incomplete. Unsurprisingly, the developer is part of the Patchstack Vulnerability Disclosure Program, which signals that the developers are not handling security right and not making sure issue are fully addressed.
…
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:
One of the changelog entries for the latest version of the WordPress plugin PrettyLinks is “Minor bugfixes and security hardening.” Looking into that, we found that there was more security hardening that probably should be done.
…
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]
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:
…
Today our Plugin Vulnerabilities Firewall stopped an attempt to exploit a recently fixed vulnerability in a WordPress plugin on our own website:
The developer of the WordPress plugin Download Manager has continued to not secure their plugin against authenticated persistent cross-site scripting (XSS) through shortcodes. We looked at that in the past. They didn’t work with us to get the problem fully resolved or get it done on their own. Since then, in version 3.2.98, a changelog entry suggested another attempt, “Fixed a shortcode parameter sanitization issue with the all downloads shortcode ( reported by Jack Taylor from Wordfence )”. Then a changelog for version 3.3.00 suggested another attempt, “Fixed a parameter sanitization issue with short-code [wpdm_login_form].” In looking over the code, we confirmed there is at least one more issue. We would recommend not using the plugin unless the developer shows they are committed to finally fully securing the plugin.
…
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]
