Login

Patchstack News

30 May 2025

Patchstack Now Withholding Misappropriated Information Needed to Secure Plugins in WordPress Plugin Directory From WordPress

Last week, we posted how WordPress had left a known vulnerable WordPress plugin with 100,000+ installs that is being targeted by a hacker in the WordPress Plugin Directory. The plugin continues to be in the plugin directory despite one of the Team Reps for the Plugins Team, David Perez, and the Senior Team member of the team, Samuel (Otto) Wood, being informed of that.

It turns out that there is another party partially responsible for the situation. It is a party that has already been engaged in unethical behavior and things have gotten worse now. [Read more]

22 May 2025

WordPress Hasn’t Addressed Hacker Targeted Plugin With 100,000+ Installs That Has Unfixed “Critical” Vulnerability

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:

[Read more]

12 May 2025

WordPress and Security Providers Fail to Make Sure All Plugins Containing Known Vulnerability Have Been Addressed

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]

23 Apr 2025

Developer of Really Simple Security WordPress Plugin Failed to Fully Address CSRF Vulnerability

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]

14 Apr 2025

Wordfence’s Unethical Behavior Caused Weeks Long Delay in Fix of Serious Vulnerability

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]

8 Apr 2025

WordPress Security Providers Failing to Warn About Vulnerability in Plugin Hacker Likely Targetting

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]

14 Feb 2025

Hacker Probing For WordPress Plugin With Many Vulnerabilities That Wordfence and Other Providers Incorrectly Claimed Were Fixed Last Year

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]

4 Feb 2025

Patchstack Isn’t Actually Patching Vulnerabilities

You would reasonably think that a security company named Patchstack would be focused on patching security vulnerabilities, but it turns out they are not. In fact, they are actually making it harder for vulnerabilities to get patched.

If you head over to Patchstack’s homepage, they currently claim at the top of the page to offer the “fastest protection for WordPress security vulnerabilities” and claim to have
9,100+ virtual patches to protect you:” [Read more]

31 Jan 2025

WordPress (and Open Source In General) Have a Big Problem With a Lack of Vulnerability Transparency

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]

31 Jan 2025

Patchstack Admits to Failing to Basic Due Diligence With Vulnerability Reports, Which Leads to Vulnerabilities Remaining Unfixed

Last May, we looked into a claim from Automattic’s WPScan that a vulnerability in the 400,000+ install WordPress plugin Kadence Blocks had been fixed in its implementation of WordPress blocks. They provided little information and didn’t show any evidence the issue had been resolved. There was the further problem that the changelog for the version they claimed the issue was fixed in had no mention of a security fix. We did find the proof of concept they provided stopped working in that version. But we also found that there was plenty of code related to the issue that was still not properly secured. We confirmed that at least one instance was still vulnerable.

Before warning our customers about that, we attempted to work with the developer, StellarWP, to address that. On the website of their Kadence brand, there is a page on responsible disclosure that starts this way (emphasis ours): [Read more]