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:
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]
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]
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]
Today we saw what appeared to be a hacker probing for usage of the WordPress plugin WP Compress on our websites. The probing was done by requesting a file from the plugin if the plugin had existed on our website, /wp-content/plugins/wp-compress-image-optimizer/readme.txt. We don’t use that plugin on that website or any of them. So what might explain a hacker’s interest in the plugin? Last year the WordPress security provider Wordfence claimed that a vulnerability had been fixed in the plugin, of a type that sounds like it could explain a hacker’s interest. Here is part of their description:
This makes it possible for authenticated attackers, with subscriber-level permissions and above, to edit plugin settings, including storing cross-site scripting, in multisite environments. [Read more]
Looking back at some things while preparing a post about a WordPress security provider misleading people about the European Union’s Cyber Resilience Act, we ran across a letter that was put out by WordPress and several other open source CMS. In that they made this claim about fixing potential vulnerabilities in open source code:
Tens of thousands of developers are empowered to identify and fix potential vulnerabilities, because all FOSS code is made publicly available — unlike proprietary software code that is kept secret. [Read more]
We are currently looking in to yet another problem with handling of security by Awesome Motive and the Security Reviewer from the WordPress Plugin Review Team. In doing that, we ran across another example of the incredible sloppy work done by prominent providers of data on vulnerabilities in WordPress plugins.
In January, the WordPress plugin SimpleMap Store Locator was closed on the WordPress Plugin Directory for an unspecified “security issue.” [Read more]
Two days ago, a news story about WordPress websites being hacked was published titled “Hunk Companion WordPress plugin exploited to install vulnerable plugins.” The last part of that is important, but was largely ignored in the story. With the only mention saying that “While investigating a WordPress site infection, WPScan discovered active exploitation of CVE-2024-11972 to install a vulnerable version of WP Query Console.” That plugin was closed on the WordPress Plugin Directory on October 21.
When it comes to whether Matt Mullenweg or WP Engine are the bad guys in the recent, the reality is that they both have played a decidedly harmful role in the security of WordPress plugins. Sometimes that comes from them working together. Last year, we noted that WP Engine was falsely claiming that a popular WordPress plugin contained a security vulnerabilities. That was caused by them using a known unreliable source of vulnerabilities, WPScan. Incredibly, WP Engine’s VP of security admitted earlier in the year they haven’t done due diligence with WPScan’s data:
We know that there are other options out there, but given the sense of completeness and alerts for ALL relevant plugins, we never had a need to go crosscheck WPScan against anyone else. [Read more]
Last week, we had someone contact us about addressing an unfixed vulnerability in a WordPress plugin. In taking a quick look at that, we found the vulnerability had been fixed over three years ago. So why was this person asking about that now? Well, it turned out in part, that the security provider Patchstack, as is often the case, didn’t vet the information they simply copied from another provider.
Based on the name they used for the vulnerability, we could determine that Patchstack is the original source for this person’s information. Whether they got it directly from Patchstack or from someone in turn using their data, we don’t know. If you look at Patchstack’s listing for the relevant vulnerability, they don’t provide even basic information about the vulnerability. But they did say that it hadn’t been fixed and was in version 4.7 of the plugin. [Read more]
