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]

30 Jan 2025

Developers of Beaver Builder Didn’t Disclose They Were Updating Known Vulnerable Library in Plugin

Over the past couple of weeks we have been posting about popular WordPress plugins that are using outdated versions of third-party libraries that have been disclosed by the developers of the libraries to contain security issues. Those have involved situations where the developers haven’t fixed those, including in one instance where the developer was notified back at the end of October. With another plugin also using a vulnerable version of the same library, DomPurify, Beaver Builder, they at least updated the library after we notified them of the issue. We don’t know if they were notified of it before. You would hope they would have, since the developer disclosed the vulnerability on October 24. What the developers of Beaver Builder didn’t do is to disclose they were doing that.

They don’t provide any changelog on the WordPress plugin directory: [Read more]

29 Jan 2025

WordPress Plugin Developers Directing Vulnerabilities Reports To Patchstack Doesn’t Signal They Take Security Seriously

Earlier in the week, we talked about how the developers of a security solution were failing to show the WordPress community (and their wider audience) that their scores were providing a meaningful and useful measure of security. We also talked about a WordPress security provider, Patchstack, was once again being dishonest. While preparing that latter post, we noticed they made this case for plugin developers having vulnerability reports directed away from them to Patchstack:

Having a VDP security program is a signal to your users that you take security seriously and your software is trustworthy. [Read more]

27 Jan 2025

Patchstack Apparently Didn’t Take Basic Step to Get Unfixed Exploitable Vulnerabilities Fixed Before Disclosing Them

Last week WordPress security provider Patchstack disclosed what they claimed was an unfixed exploitable vulnerability in a WordPress theme and one in a related WordPress plugin. We say claim, because some of the information they provided appeared on its face to be very wrong. Early in the post, they wrote that “code that handles user input didn’t have any authorization or nonce check.” Code that handles user input doesn’t necessarily require authorization or a nonce check. For example, doing a search on a WordPress based website doesn’t require either of those things, despite involving user input. A more salient point is they then promptly showed the code and that not only contained a nonce check, but even had a comment about it, “First check the nonce, if it fails the function will break:”

[Read more]

27 Jan 2025

OpenSSF Scorecard’s Developers Are Not Providing Evidence That The WordPress Community Should Trust its Results

As described by the developers, the OpenSSF Scorecard “assesses open source projects for security risks through a series of automated checks” to “help users as they decide the trust, risk, and security posture for their use case.” Considering the widespread belief that WordPress plugins are not secure, which comes from a combination of very real problems and a lot of very false claims, the scorecard could be rather beneficial for WordPress plugins. The scorecard also is the inspiration for our Plugin Security Scorecard, which is a reasonably similar scorecard focused specifically for WordPress plugins. We include a link to the results of the OpenSSF Scorecard for scored third-party libraries and WordPress plugins with a million or more installs. That being said, the developers are not providing the evidence to trust the results it produces to provide a meaningful measure of software’s security. A new blog post on their website doesn’t address that when seeking greater adoption by open source projects.

In July, we noted a number of issues that we ran across while looking at the results for WordPress plugins. Some were more serious than others. It had problems detecting the license of plugins, which doesn’t really even seem relevant to vetting the security of the software, but had a low effect on the score. More problematic was that another component of the score, which can lower the score for projects not doing something that they don’t need to do. Which even the scorecard’s documentation acknowledges. That month we also noted that Google, which is heavily involved in the scorecard, was using various third-party libraries in one of their WordPress plugins despite them getting low scores. [Read more]

27 Jan 2025

Patchstacks’s Vulnerability Disclosure Program (VDP) Goes Against Important Requirements of EU’s Cyber Resilience Act

In October, the European Union approved the Cyber Resilience Act (CRA) after two years of development. It seems well thought out, probably best shown with the authors understanding the harm that security providers’ own bad security often creates. Unfortunately, in the run up to passage, WordPress and others had tried to portray it as having negative effects on open source software (while also providing a misleading portrayal of security handling at WordPress). That is, despite it actually requiring for-profits entities taking advantage of open source software being required to help secure it. Also, unfortunately, an unscrupulous WordPress security provider is trying to mislead the WordPress community as what the act entails to continue harmfully directing vulnerability reporting away from developers.

That provider being Patchstack, here is how it mentions complying with the CRA through them on a page on its website about their vulnerability disclosure program (VDP): [Read more]

24 Jan 2025

New Insecure WordPress Plugin Marketed With Fake Norton Secured and (Retired) McAfee SECURE Security Seals

Yesterday, we reported on a new plugin from a WordPress plugin developer Brainstorm Force with a long track record of poor security, unsurprisingly was also insecure. One thing that we noticed while looking into that is on the homepage for that new plugin, SureDash, was that midway down the page, there are a couple security seals, Norton Secured and McAfee SECURE, around the logo for PayPal:

[Read more]

24 Jan 2025

WordPress Plugin Review Team Reviews Failing to Catch Basic Security Failure (Including in a Plugin From the Team’s Security Reviewer)

At the end of last year, one of the team reps for the team running the WordPress plugin directory provided an assessment on what the team had been up to. It incredulously credited one past member of the team for a “magnificent legacy” of a scanner tool, despite it being no secret that person had blocked efforts for years to improve the team’s scanner tool (and more generally blocked efforts to address the problems they were causing). Beyond that, it made repeated claims about the team’s handling of security, including this in the first paragraph:

Throughout this time, we remained focused on our primary goals: enhancing security, improving the review process, and fostering community engagement. [Read more]

23 Jan 2025

New Plugins From Awesome Motive and Brainstorm Force Continue Developers’ Failure to Implement Basic Security

We release advisories warning about WordPress plugin developers who have a repeated track record of failing to handle security well. A reasonable question to ask is if a backward-looking determination is helpful or if past is not prologue with that. A week ago, we looked at an example of a developer continuing to fail that we ran across. This week we ran across another test of this, as two developers we have released advisories for have new plugins available in the WordPress Plugin Directory.

Awesome Motive

For one of those developers, Awesome Motive, we just issued our advisory on December 11. Nine days later, they introduced the plugin WPConsent to the WordPress Plugin Directory. The issue that led to us finally issuing that advisory was a continued failure to address AJAX accessible functions lacking a capability check in the 6+ million install plugin WPForms, even after fixing a vulnerability caused by that. That is really basic security, so a major plugin developer shouldn’t be failing on that front. Yet it also is the case with WPConsent. [Read more]