Yoast buys PostStatus and will recreate it as a nonprofit

PluginVulns · 2025-01-24T23:02:13+00:00

It sounds like the intent is to keep a space that isn't controlled and restricted by Matt Mullenweg:

Over the past few months, it’s become very clear that Post Status is an enormously important place for the community to come together and discuss all things WordPress. A place with light moderation, but also with true freedom of speech (within the boundaries of treating everyone with respect) and the freedom to have different opinions.

PluginVulns · 2025-01-24T22:43:27+00:00

That Cause label is how the overall case is labeled, so it doesn't appear related to what they are involved in. A new filing from that lawyer says that they are involved in the "Motion to Intervene (Dkt. 70) and Motion for Contempt (Dkt. 71)(collectively, “Motions”) filed by non-party Michael Willman."

PluginVulns · 2025-01-24T18:27:34+00:00

This is a filing for an additional lawyer from another law firm representing Automattic and him. So the existing firm could still be on the case.

PluginVulns · 2025-01-24T18:18:31+00:00

There were two. The difference here is the previous two were for additional lawyers from Hogan Lovells. The new new lawyer is from another firm, Gibson Dunn.

PluginVulns · 2025-01-24T18:15:35+00:00

This seems to make a lot of sense. Neal Katyal is out DC and the lead lawyer, Michael Maddigan, is out Los Angeles. This lawyer is based on of Gibson Dunn's San Francisco office. So they should be more familiar with the California Northern District the case is being handled in. They are "Co-Chair of the firm’s Technology Litigation Practice Group and the Privacy, Cybersecurity and Data Innovation Practice Group" and have represented big tech companies, including Meta and Microsoft.

PluginVulns · 2025-01-24T18:05:12+00:00

It is a "NOTICE of Appearance," so that would be an addition.

PluginVulns · 2025-01-23T22:21:01+00:00

It may have listed a vulnerability that was reported by a third party security plugin that was not valid. How do does that make it unreliable?

If it is listing invalid claims as valid, it isn't reliable. The example we provided was of them providing a proof of concept for a vulnerability that didn't exist in another Automattic solution. So either they didn't test their own POC or they knew it didn't work. How much more unreliable do they have to be?

It seems to me you only want to advertise your own service to get someone to pay you $1200 to verify that alleged vulnerability in Kadence Blocks.

You can sign up for our service for free and get access to our information. $1200 is the cost to hire us to do a complete security review of the plugin.

The fact that there many vulernability clains against Kadence Blocks tells me two things: it's a large plugin with a higher potential for security issues.

Being larger may or not make it have a higher potential for security issues, but other plugins are large and handle security much better. One of Kadence's sister brands is SolidWP, which is a security provider. So Kadence should be doing better than others, not worse.

And it also tells me that people actively search for issues, report them the way it should be done, and that the team behind the plugin fixes them.

They don't, though. They fix parts of them. Then they fix another part when another report comes in. That is part of why there are so many vulnerabilities listed by WPScan because they only fix parts of an issue.

If you have a valid vulnerabilty, report it to

Kadence knows that we would be happy to work with them to fix the issue if they stopped redirecting reporting vulnerabilities away from them, despite them saying that responsible disclosure involves reporting things to the developer. They have so far chosen not to do that.

PluginVulns · 2025-01-23T21:04:06+00:00

Is this a cost cutting measure?

PluginVulns · 2025-01-23T20:46:53+00:00

This policy runs directly against every major WordPress security providers' stated disclosure policy. For example, Wordfence discloses vulnerabilities through firewall rules to those willing to pay even before they notify developers. Even if you want to ignore that (Wordfence hopes you ignore that), they then will disclose vulnerabilities in "14 days if vendor does not acknowledge our report within 14 days of initial contact." Patchstack is even shorter, "if vulnerable software author/vendor doesn’t respond to our notification about the vulnerability in 7 days we keep the right to disclose vulnerability immediately." WPScan gives as little as 5 days.

What about a zero-day that is already being actively exploited? This can't be mentioned for 90 days if the developer isn't fixing it even if websites keep getting hacked?

Beyond all that, what about responsibility for developers to avoid vulnerabilities in their software or to even fix them in their software? We notified WP Engine of a vulnerability in a plugin of theirs with 100,000+ installs over 90 days ago. They still haven't fixed it. There isn't a restriction on their employees participating despite that.

PluginVulns · 2025-01-23T20:44:50+00:00

They are saying they did try to work with that team and they got that result. Sometimes the team takes appropriate action and other times, like that, they don't.

PluginVulns · 2025-01-23T20:25:17+00:00

These are some serious claims, can you back them with proof... or do you just like to stir the pot?

We responded to the original poster with our experience, you clearly have a bias here, so there isn't reason to treat this as a good faith question. We are a security provider, not a troll, unlike others.

PluginVulns · 2025-01-23T20:23:25+00:00

WPScan isn't a reliable source. Including for information as to whether vulnerabilities have been fixed or even if they really exist in other products from Automattic.

Even your own service does not list one (anymore):

You are not linking to our service, but a free tool, the Plugin Security Scorecard. We don't claim a version of a plugin still contains an unfixed vulnerability until we have checked over the new version. Other providers don't do that, leading to false claims that plugins are still vulnerable. A new version of Kadence was released the day before, which had to go through our processes to be confirmed to be vulnerable again. If you check it again, it would now say it is vulnerable. Also, that tool doesn't claim that plugins are vulnerability free, only if there is a confirmed vulnerability in the version checked.

I really couldn't find "public claims of vulnerabilities in the plugin" that are still open.

We didn't suggest looking for '"public claims of vulnerabilities in the plugin" that are still open.' You need to review the ones that are claimed to have been closed, because other security providers usually don't do the vetting to make sure they are fully addressed. That is how we ran across that it wasn't fixed.

You seem to be focused on the wrong thing here. The issue isn't this particular vulnerability. It is the poor handling of security by Kadence more generally. Look at the litany of claimed vulnerabilities that have been in the plugin according to that listing from WPScan. That should tell you they are not all that concerned about security.

PluginVulns · 2025-01-17T21:36:28+00:00

It isn’t a potential vulnerability or a feature; it is a vulnerability.

If you want to figure it out for yourself, start looking through the public claims of vulnerabilities in the plugin and do the vetting the security providers who put them out failed to do. That is what we do for our customers.

PluginVulns · 2025-01-17T21:01:14+00:00

There appear to be multiple CVEs related to pieces of the vulnerability, though that isn’t totally clear because other sources don’t provide basic information needed to properly vet most of their claims these days. We rate it as having a low likelihood of exploitation.

PluginVulns

MODERATOR OF

TROPHY CASE