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]
Yesterday, we had a series of strange hacking attempts launched against our website. Here, for example, was one attempt that was logged by our systems:
118.179.26.34 8 /wp-admin/admin-ajax.php Array
(
[action] => wp_ajax_some_action
[sql] => 1 UNION SELECT user, password FROM wp_users
) [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]
Today we got a phishing email claiming to warn us that our website had “a critical security vulnerability identified in the WooCommerce platform on April 28, 2025″ and telling us to install a security patch. Here is the full email:
Dear WooCommerce User
We are contacting you regarding a critical security vulnerability identified in the WooCommerce platform on April 28, 2025.
Warning: Our latest security scan, performed on May 6, 2025, has verified that this critical vulnerability directly affects your website:
pluginvulnerabilities.com
Vulnerability details
This vulnerability involves Unauthenticated Administrative Access, which could potentially allow attackers to gain unauthorized access to your website’s administrative operations. If taken advantage of, this could compromise sensitive user data, including customer information, order details, and credit card data, potentially leading to unauthorized payments, extensive data theft, or even losing total control over your website.
We urge you to take urgent measures to secure your store and protect your data.
Measures you must follow
Click the button below to download the security patch from our official website:
Once you have downloaded the patch, please follow these steps: [Read more]
Part of the reason that WordPress remains so insecure is that you have a WordPress security industry largely built around profiting off issues not being properly addressed instead of working to get them properly addressed. The developer of the most popular WordPress security plugin, Wordfence, has been a prime offender for years. When there is a chance to help improve the security or a chance to promote themselves, their choice has repeatedly been to promote themselves. One area is in with server-side request forgery (SSRF).
WordPress has a set of functions for making requests to URLs that are supposed to prevent SSRF. Here is how that is described with the function wp_safe_remote_get(): [Read more]
WordPress is supposed to be an open source project, but a lack of openness is a reoccurring issue. That has a negative impact on security.
According to the Security page for WordPress, “[t]he WordPress Security Team works to identify and resolve security issues across the WordPress core software.” The team is supposed to be rather large: [Read more]
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]
As part of starting a security review of the WordPress plugin Eventin after it was chosen by our customers to receive a review, we ran the plugin through our Plugin Security Checker. That identified the possibility of a server-side request forgery (SSRF) issue in the plugin:
A week ago we posted on our finding fairly stunning examples of poor security in WordPress. Those examples suggest that WordPress hasn’t had a comprehensive security review since at least 2009. The security page for WordPress would seem to say that is something that the “WordPress Security Team” should be addressing:
The WordPress Security Team works to identify and resolve security issues across the WordPress core software, harden the software against threats such as the OWASP Top Ten, and provide guidance across the ecosystem. [Read more]
