18 Jan

Not Surprisingly WordPress Vulnerabilities Didn’t Triple in 2018

A week ago we wrote this:

A good rule of thumb based on what we have seen over the years is that stats on security are probably not accurate. So it isn’t surprising that when we looked into a claim by a company named Imperva that WordPress vulnerabilities tripled in 2018, it was a mess, but that hasn’t stopped security journalists from repeating the claim.

In that post we had also noted the poor coverage of the claim by a security news outlet, Threatpost. Before we did that we had contacted the listed editorial contact for that website, Thomas Spring, to note the issues with their article. We have yet to hear back from them, so we went back to the article to see if there had been a change and there had.

The change though didn’t correct anything we had noted, like this obviously incorrect line:

Automattic, the owner of WordPress, did not immediately respond to a request for comment from Threatpost.

Automattic doesn’t own WordPress.

What was changed was that the headline claim of the article was radically changed. The headline now read “WordPress Vulnerabilities Up 30 Percent in 2018”. That is significant drop from the previous claim that they tripled.

At the bottom of the article this was added:

This article was updated on Jan. 14 at 4 p.m. EST, to reflect new statistics about WordPress vulns based on Imperva’s report, due to an inconsistency with stats that made it into the initial report. “Due to a data transfer error, some of the 2017 figures were incorrectly reported; this version of the blog has been corrected. This error did not affect our 2018 statistics, nor our conclusions,” Imperva said.

It is hard to understand how this didn’t impact their conclusions since WordPress vulnerabilities discovered increased by a 10% of their original claim.

That there were data issues really surprising, considering what we noted last week:

Looking around various source to try to find a match or understand their sourcing we couldn’t find anywhere near 11 reports of vulnerabilities in the first plugin shown, Event Calendar WD. In fact we only found one, if you count each change made related to that vulnerability you would to more than 11, so we can’t figure out where the figure might have come from. What makes that more problematic is that the other portions of their post don’t seem to be written by someone that understands the topic at hand, so the accuracy of the data seems suspect to us.

Over at another outlet that ran with this, Bleeping Computer, the following update was added (emphasis ours):

The original article contained a factual error that slipped in the report we received, incorrectly claiming that WordPress-related vulnerabilities increased three times in 2018 compared to the previous year. In fact the amount of vulnerabilities related to the CMS increased by 30%. We have updated the article to correct the mistake. This does not change the fact that WordPress is the most popular CMS out there and that it received the largest number of vulnerability reports.

It doesn’t seem like the most popular CMS receiving the most reports would be news, especially considering that most of the count related not WordPress itself, but to plugins.

You might think that Threatpost and others outlets might reconsidering their sourcing in light of something like this, but as we noted last week these types of stats are generally not accurate and no amount of previous inaccuracies has changed things (the sourcing issues are a problem not just for stats based articles unfortunately). In this case even if accurate, the increase in the number of vulnerabilities discovered in WordPress plugins isn’t really all that newsworthy without understanding why they increased since the increase could be a sign of WordPress plugins getting more secure or less secure.

16 Jan

Defender Pro WordPress Plugin Flags Harmless Code in Plugin While Missing Actual Vulnerability

The most recent version of the plugin WP-Stateless was flagged by monitoring we do for a couple of reasons and in looking at those we yet another reminder of the better results caused by us doing the work that other in the security space don’t do, which leaves their customers at a large disadvantage (and if we had more customers could lead to better results for everyone using WordPress).

One of the reason it was flagged was due to our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities, which flagged possible vulnerable code that led to us finding the plugin contains an authenticated remote code execution (RCE) vulnerability.

The other was that one of the changelog entries for that version was flagged as potentially referencing a security fix:

ENHANCEMENT – Updated depreciated function flagged by security software. GitHub Issue #300.<

That was a reference to the Defender Pro plugin flagging what seems like completely harmless code. The message that plugin was showing was:

There’s some suspicious looking code in the file wp-content/plugins/wp-stateless/vendor/usabilitydynamics/lib-utility/lib/class-utility.php. If you know the code is harmless you can ignore this warning. Otherwise, you can choose to delete this file. Before deleting any files from your site directory, we recommend backing up your website.

The code reference with that was:

array_walk_recursive( $arr, create_function( '&$item, $key', 'if (is_string($item)) $item = mb_encode_numericentity($item, array (0x80, 0xffff, 0, 0xffff), "UTF-8");' ) );

How the developers of that security plugin think the average user of it would know if code like that is harmless or not is beyond us. Deleting the whole file might be overkill, if say, it was malicious code added by a hacker to a legitimate file. Deleting that particular file would cause websites to be broken if the plugin it is part was enabled, so doing a backup would be more than something that should be recommend before doing that.

We are not sure what is even supposed to make that code suspicious, but the developer believed it was due to the usage the function create_function():

The warning was shown because of the create_function, it’s deprecated and uses eval() internally.

If that is the case that seems like a good indication that the developers of the Defender Pro plugin are not really thinking through what they are doing. That is a legitimate PHP function, so just flagging its usage in an indiscriminate way is not necessarily a great idea. As we noted when considering adding a check for it to our Plugin Security Checker tool in November of 2017, at the time 19 of 100 of the most popular plugins utilized it, while at the same we couldn’t “recall it being part of any disclosed vulnerabilities in WordPress plugins”. For us we decided to only mention it usage in the more advanced mode of our tool, designed for security professional and plugin developers, since there was reason to mention it since “it is being deprecated in PHP 7.2, and the PHP documentation for it suggest that “Relying on this function is highly discouraged”, but at the same time we didn’t wanted to cause unnecessary concern (we also don’t recommend indiscriminately deleting files).

Being overzealous in flagging code might make sense if it was at least catching real security issues others are not, but in that clearly isn’t the case here, as it missed the real vulnerability. By comparison our Plugin Security Checker would have warned you about the possibility of the real vulnerability. From there if you are a paying customer of our service you could have suggested/voted for it to receive a security review that would check over that or you could have ordered the same type of review separately.

11 Jan

The Mess that is Imperva’s Claim That WordPress Vulnerabilities Tripled in 2018

A good rule of thumb based on what we have seen over the years is that stats on security are probably not accurate. So it isn’t surprising that when we looked into a claim by a company named Imperva that WordPress vulnerabilities tripled in 2018, it was a mess, but that hasn’t stopped security journalists from repeating the claim.

When we ran across the claim our first question was what the source of their data was and looking at Imperva’s post they only give a vague explanation:

 To do this, we use internal software that collects information from various data sources such as vulnerability databases, newsletters, forums, social media and more, integrates it into a single repository, and assesses each vulnerability’s priority.

They provide this chart “Top 10 vulnerable WordPress plugins”:

Looking around various source to try to find a match or understand their sourcing we couldn’t find anywhere near 11 reports of vulnerabilities in the first plugin shown, Event Calendar WD. In fact we only found one, if you count each change made related to that vulnerability you would to more than 11, so we can’t figure out where the figure might have come from. What makes that more problematic is that the other portions of their post don’t seem to be written by someone that understands the topic at hand, so the accuracy of the data seems suspect to us.

Speaking of the problematic portions, what really makes this a mess is that this company is mixing up vulnerabilities discovered in software with other things. Right above the chart they wrote this:

In Figure 8 below, you can find the ten WordPress plugins with the most vulnerabilities discovered in 2018. Please note, that these are not necessarily the most-attacked plugins.

But at another point in their post they write this:

Despite the slowed growth in new plugins, the number of WordPress vulnerabilities tripled! The explanation for this could either be the code quality of the plugins, or the fact that WordPress is such a popular CMS, which motivate more attackers to develop dedicated attack tools and try their luck searching for holes in the code.

Since this is supposed to be measure of vulnerabilities discovered the explanation for the claimed tripling could, say, have to do with improvements in spotting vulnerabilities, not that there were more vulnerabilities. That they don’t seem to understand that raises serious questions about their whole endeavor.

What seems more important is the hypothesis that “more attackers to develop dedicated attack tools and try their luck searching for holes in the code” as that makes no sense, since the vast, vast majority of vulnerabilities being discovered are not connected to attackers. Based on what we saw during the year, the new vulnerabilities being discovered by attackers that would lead others to notice the issue (its possible that more advanced attackers are exploiting vulnerabilities that are not then spotted) would run in the tens of vulnerabilities at most (and it probably in the single digits), which is nowhere near the 542 they list as the total.

Bad Journalism

As example of example of the bad journalism based on that, take Lindsey O’Donnell at Threatpost on this. The quality of the journalism is pretty telling from this at the bottom of the post:

Automattic, the owner of WordPress, did not immediately respond to a request for comment from Threatpost.

Automattic isn’t the owner of WordPress, though you might think otherwise based on what has happened related to Gutenberg, so asking them for comment is odd.

The start of the post is also quite problematic:

Despite fewer plugins being added to WordPress last year, the CMS saw an astounding tripling of vulnerabilities in its platform in 2018.

Vulnerabilities in popular content management system (CMS) WordPress are growing at a staggering rate, almost tripling in 2018, according to new web application bug research released Wednesday.

Again these are vulnerabilities discovered, so the number of new plugins should not necessarily have any correlation and the increase in discoveries could be a good thing, but that isn’t ever grappled with or discussed in their post.

10 Jan

WordPress Plugin Developers Don’t Do a Good Job of Making Sure There Plugins Are Free of Vulnerabilities They Know of

Our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins recently caught a good example of an ongoing problem we see when it comes to the developers of WordPress plugins, a failure to make sure that security vulnerabilities that have been in their plugins have been fully removed. In some cases that involves them only fixing one instance of a vulnerability in a plugin and not making sure that there are not any others in the plugin, in others, like this situation, making sure that the vulnerability isn’t in other of their plugins.

Back in October we disclosed a cross-site request forgery (CSRF)/local file inclusion (LFI) vulnerability in the plugin Companion Auto Update. We recently started checking for that type of vulnerability with our proactive monitoring and it quickly lead to us finding that another plugin by the same developer, Companion Sitemap Generator, contains it as well due to the same code that caused the issue with their other plugin.

Clearly relying on developer’s to keep their plugin secure when they fail to make sure to avoid issue they know have been in their plugins leaves a lot to be desired and that is where we come in. Our Plugin Security Checker will alert you if plugins you use possibly contain the same type vulnerable code (and possibly contain more serious vulnerable code). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

The issue occurs in a couple of files in the plugin. One of those is /dashboard/sitemap/start.php. In that file if the GET input “tabbed” exists it will be included (through use of the require() function):

21
22
23
24
25
26
27
if( !isset( $_GET['tabbed'] ) ) { 
 
	require( 'dashboard.php' );
 
} else {
 
	require( $_GET['tabbed'].'.php' );

Through path traversal that code could allow any file with a .php extension to be included, causing the code in the specified file to run.

That file is run when the function csg_dashboard() is run:

224
225
function csg_dashboard() {
	require( 'dashboard/sitemap/start.php' );

And that in turn runs when accessing the plugin’s Sitemap page, which is accessible to those with “manage_options” capability:

182
add_submenu_page( 'tools.php', __('Sitemap', 'companion-sitemap-generator'), __('Sitemap', 'companion-sitemap-generator'), 'manage_options', 'csg-sitemap', 'csg_dashboard' );

Normally only Administrators have that capability. Seeing as Administrators can normally do whatever they want, them intending to use that to cause a file to be included wouldn’t be a vulnerability since among other things they could normally remove security code that would restrict something like this from being possible or just upload a plugin that runs any code they want already.

But in this case, an attacker can cause this to happen without the Administrator intending it since if the attacker could get the Administrator to visit a URL they specify they can cause the local file inclusion vulnerability to be exploited.

Proof of Concept

The following proof of concept will cause a file named test.php in the root directory of the WordPress installation to be included, when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/tools.php?page=csg-sitemap&tabbed=..%2Ftest
17 Dec

WordPress Plugin Directory Team Close Plugin Due to Fake Vulnerability Report

When it comes to inappropriate behavior of the moderators of the WordPress Support forum that has lead to us full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, that inappropriate behavior often has the impact of covering up problems created by those on the WordPress side of things. Whether they are intending to do that to cover up things or not isn’t clear, but the person that appears to be in charge of the moderation, Samuel “Otto” Wood, wears a number of other hats when it comes to WordPress, so there are obvious potential conflict of interest issues. One of the hats he wears is being a member of the six member team running the Plugin Directory, which screwed up in fairly obvious way a few days ago involving plugin CSS & JavaScript Toolbox and then a moderator shut down the possibility of pointing that out.

If you follow our blog you might have seen our post on Friday that mentioned that a false report of a vulnerability in that plugin and quite a few others. We explained the reason they were false as follows:

While the person behind these reports believes that the file they are listing for each of the plugins is a database backup, in reality they are files that came with the plugins. It hard to understand how they didn’t realize that as the contents are exactly the same for the same plugin file on every website they listed, but they apparently didn’t.

In the case of this plugin it should be rather obvious as to what is going on as if you looked at the file, named uinstall.sql, it simply contained SQL code that would run when uninstalling the plugin. Here are the first few lines:

/*
* Delete CJT Tables
*/
DROP TABLE IF EXISTS #__cjtoolbox_authors;
DROP TABLE IF EXISTS #__cjtoolbox_backups;
DROP TABLE IF EXISTS #__cjtoolbox_blocks;

That wouldn’t do anything if you just directly requested file and isn’t a security issue as far we can think of.

Apparently the head of the Plugin Directory, Mika Epstein, couldn’t understand that as there is a topic on the forum for explaining why the plugin had been closed:

Mika Epstein from WordPress has emailed and alerted me to a medium-risk security vulnerability, which needs patching. We would like to thank Mika and the WordPress team for alerting us to this issue and hope to release a patch as soon as possible.

We apologise for any inconvenience.

Who should be apologizing are Mika Epstein and the Plugin Directory team for inappropriately handling this. No one can’t point that out though, since one the frequently problematic moderators of the WordPress Support Forum, Andrew Nevins, closed the topic with this message:

Thank you for your transparent post Damian. We’re going to use this as an announcement and close it to new replies.

It would be great if the WordPress folks actually allowed transparency instead of covering up problems they cause like this. That transparency would include not inappropriately closing topics and allowing for outside oversight of their closures of plugins, as the current process is ripe for abuse.

The change made that is somehow supposed to fix this is to change the extension of the file from .sql to .php, which doesn’t actually do anything security wise as far as we can think.

13 Dec

The Strange Behavior of Moderators of the WordPress Support Continues With Response to Our Protest

When it comes to the inappropriate behavior on the part of the moderators of the WordPress Support Forum that lead to us full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up one thing that stands out is how strange so much of it is. If the moderators were, say, being paid off to delete reviews of plugins you could understand the motive behind it, but with what is going on so much is head scratching. Why would a moderator delete a reply just saying thank you, which is something that we have run across moderators recently as well as years ago. So it probably isn’t surprising that the first direct response from someone on the WordPress side of things to our protest doesn’t even really make sense.

That comes from one of the problematic moderators and starts with this:

That would make sense if we doing all this with a mistaken belief that doing things that way was more efficient to report vulnerabilities instead, but that isn’t the case at all or even close to be related to to what is going. How this person wouldn’t understand that is really hard to understand as we have a standardized message we leave on the Support Forum when mentioning that we have disclosed a vulnerability and it starts with this:

Due to the moderators of this forum continued refusal to operate in an appropriate fashion we have started full disclosing security vulnerabilities and only notifying developers of those disclosures through this forum.

Why that person would think that we are doing this for some entirely different is hard to understand (though it seems like it might not be the first time our clear explanation has been totally ignored). We also explain the same thing on each post for these full disclosures of vulnerabilities.

As for that being argument what we are doing it makes no more sense.

Making things less efficient for the people on the WordPress side of things wouldn’t be a negative for us since we are trying to get them to change their behavior and that would incentivize them to change, so that wouldn’t be a good reason for us to stop.

This process is actually more efficient for us then the reasonable disclosure we previously did and we would go back to if the inappropriate behavior stopped. With that process we have to spend a lot of time with the developers of plugins and it isn’t always in a productive fashion. For example, have to deal with developers arguing there isn’t a vulnerability instead of just working with us to get it fixed. And there are sometimes where we are sitting on knowledge of a vulnerability for a month because we were told that a vulnerability would be fixed in that window and it isn’t. In the meantime our customers that are paying to be alerted about vulnerabilities are left in the dark. Making things, when we hopefully can go back to reasonable disclosures, more problematic is that many of the vulnerabilities we are discovering now are things that our automated tool, the Plugin Security Checker, also flags the possibility of, which makes sitting on vulnerabilities more concerning. Full disclosure certainly has big downsides as well, but it does make our job easier.

Not surprisingly considering the track record of the moderators getting things wrong frequently, another part of the tweet isn’t true. It also speaks to the fact that what we are doing is actually more efficient for us, since actually dealing with vulnerabilities all the way through is difficult (and made more difficult when the moderators get in the way of doing that). Here is the claim:

[we] notify the plugins team. The plugins team acts on your report.

The reality is that frequently somewhere in that process things are going wrong. Take the arbitrary file viewing vulnerability we disclosed a couple of days ago in the plugin WebP Express. The vulnerability still exists in the plugin and is still in the Plugin Directory despite it looking like hackers are already moving to exploit it. That is far from the only vulnerability that hasn’t been dealt with. Amazingly in our replies to the moderator we pointed out that vulnerability was being exploited and yet a day later still nothing has been done (these people really don’t seem to care about security, unless it is to get in the way of others trying to properly deal with them).

In our replies we had also mentioned the other points made above. You would think the moderator would try to dispute that they are acting inappropriately or counter something we said, but instead there was another response that seems completely unrelated to what is actually going on:

In response we pointed out that part of the inappropriate behavior is there breaking the rules of the Support Forum that they are supposed to be enforcing and that there is an easy way for this to stop, as soon as moderators stop acting inappropriately, we stop what we have been doing, which led to this response:

Those message from that moderator seem to go a long way to explain the mess anyone trying to interact in the Support Forum has to deal with since you have the people that moderate it who seem to have a distinct lack of ability to pay attention what they are getting involved in whatsoever.

12 Dec

WordPress Team Stops Warning To Developer of Vulnerability in Plugin While Probing For Usage of the Plugin Has Already Begun

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up and only trying to notify the developer through the WordPress Support Forum. That creates more of a problem if the vulnerabilities are likely to be exploited, like the arbitrary file viewing vulnerability we disclosed yesterday in the plugin WebP Express is. Thankfully with that type of vulnerability it usually doesn’t lead to websites being hacked. You would think that someone on the WordPress side of things might step in to make sure the moderators behavior is cleaned up so that these full disclosures can end, or barring that, make sure to keep on top of these disclosures to avoid those causing major issues. That doesn’t appear to be the case.

While our message to the developer on the Support Forum to let them know of the issue right after we disclosed it was blocked from being shown to them, that not at all surprisingly, unless you are the WordPress team, hasn’t stopped hackers from becoming aware of it already. Earlier today we had a couple of requests that look to be probing for usage of the plugin by way of a request for a CSS file from it, /wp-content/plugins/webp-express/lib/options/css/webp-express-options-page.css. Those came from IP addresses in China that appear to belong to Alibaba.

In the past with a vulnerability where it looks like it was being exploited we warned people that are not even customers through the free data that comes with the companion plugin for the service, but WordPress closed that on the Plugin Directory, so they are stopping people from getting a free and easy option to warn them about the most vulnerable plugins. So unfortunately if you want to be keeping abreast if plugins you are using have serious vulnerabilities, at this time our service is the only real option, as other data sources and other security companies are way behind in warning about vulnerable plugins (WordPress refuses to provide any warning).

If you want to get ahead of security issues in WordPress plugins you use then our Plugin Security Checker is good place to start since it can alert you if plugins you use contain similar code that could contain the same vulnerability (and if those plugins possibly contain a lot of other serious vulnerabilities). The tool is continually being updated, so these days checking your plugins frequently could lead to warning about an issue it didn’t before (the check that identified the possibility of this vulnerability was only added on Monday afternoon). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over the possible issue or you can order the same type of review separately.

10 Dec

WPScan Vulnerability Database Weeks Behind in Warning About Exploited Vulnerability in WordPress Plugin

On Friday we noted that during the month of November we not only added many more new vulnerabilities in WordPress plugins to our data set than the widely used WPScan Vulnerability Database (50 to 11), but we actually disclosed more vulnerabilities ourselves than they added in total during the month (21 to 11). Considering that all the vulnerabilities we discover are publicly disclosed and you can even access a RSS feed just of them, it doesn’t speak highly of the quality of their data set to be missing them.

The handling of one of the vulnerabilities we disclosed is of particular concern for anyone relying on their data, as it was an option update vulnerability we disclosed on November 12 that looks to have been on hackers’ radar by at least November 15. It was only added to WPScan’s data on the December 7th:

That kind of thing has wider repercussions as you have people that unknowingly rely on their data in deciding whether to update plugins and wouldn’t even know about the limits of their data since they are not being properly warned about by companies reusing the data (it gets as worse as one company not warning their customers about the quality of the data actually goes further by lying and claiming that the WPScan data is “confirmed/validated” when it explicitly isn’t).

Also noticeable in that listing is that they fail to credit us, which isn’t a one off issue.

We disclosed a remote code execution (RCE) vulnerability on November 30, which WPScan falsely claims was publicly published on December 3 and which they only got around to adding on December 6:

The last of our recently disclosed vulnerabilities they managed to add seems to be missing more important information than attribution to us, as they list a vulnerability in Ultimate Member as being a cross-site request forgery (CSRF) vulnerability:

CSRF, involves causing someone else to take an action they didn’t intend to, so what you can do with that is rather important. For example, disabling an advertising notice in a plugin wouldn’t really be something anyone would care about. In this case though it would have allowed remote code execution (RCE), which is a fairly serious issue.

07 Dec

WordPress Support Forum Moderator Thinks Hiding Security Issues is a Bad and Good at the Same Time

When it comes to the mess that is the moderation of the WordPress Support Forum a central problem is the moderators seem to be unwilling to allow people to discuss things that disagree with their beliefs. So for example last week we mentioned how at first replies were deleted and then a whole topic closed when people put forward the idea that people shouldn’t be left in the dark about closed plugins. The moderator that seems to be at the heart of that was the frequently problematic, Jan Dembowski, who doesn’t believe that even asking about closed plugins is a valid support question (which we still don’t understand).

That same moderator popped up in the email alerts we have for the forum to monitor for discussions about security issues a couple of times in the last week where they seemed to highlight that these moderators are not thinking through what they are saying and doing, which is a big problem when they stop discussions that could help to avoid the unnecessary hacks of WordPress websites due to the poorly thought out actions of the WordPress Plugin Directory team (like occurred recently with plugins WP GDPR compliance and AMP for WP).

Here was that moderator putting forward the reasonable notion that security through obscurity doesn’t work a week ago:

This is really a bad idea and always has been. Securing your site keeps you safe, hiding things like that does not accomplish anything.

As this are areas of security to protect ones site and make it less easy to finding vulnerabilities on ones site.

That’s not security and would leave your site exploitable. The boys that probe your site do not look first, they just try the exploits that’s in it’s catalog.

Based on that you think that they would understand that hiding that there are unfixed vulnerabilities in WordPress plugins that hackers are exploiting would be a bad idea seeing as the hackers are going to exploit them even if people using the plugin are not aware of it, but here they were the day before saying you should never warn people about unfixed vulnerabilities:

When a plugin is taken down there is no information on the reason why it was done. I believe it has to be mandatory.

That’s not a good idea unless it’s something that has been resolved already.

 

It does not serve anyone’s interests to inform users about the vulnerability before it is remediated.

Those two things don’t go together, yet somehow this person just a day apart stating both of them.

If exploited vulnerabilities in WordPress plugin were always promptly fixed that stance would be of limited concern, but some of them never are and you can’t even discuss doing something about that on the forum either.