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.

30 Nov

Samuel “Otto” Wood Keeps Making it Seem Like He Wants WordPress Websites to Be Unnecessarily Hacked

On October 29th we detailed a vulnerability that had been fixed in the plugin AMP for WP – Accelerated Mobile Pages and started warning our customers if they were using a vulnerable version. What made this problematic was that while there was a fixed version available, since the plugin was closed, people could not use the normal update process in WordPress to update to it (though we were available to help our customers do that).

The lack of the ability to update was a serious issue as on November 5, when the plugin was still closed, we noted this:

A week ago we put out a Vulnerability Details posts with the details of a vulnerability in the plugin AMP for WP – Accelerated Mobile Pages, which had been closed on the Plugin Directory recently, so if you were already customer of our service and using that plugin you would have been warned about that particular issue, as well as the general poor security of the most recently released version of the plugin. It looks like hackers are aware of that as well now, as yesterday we had a series of requests requesting files from the plugin that looked to be probing for usage of it:

  • /wp-content/plugins/accelerated-mobile-pages/readme.txt
  • /wp-content/plugins/accelerated-mobile-pages/README.md
  • /wp-content/plugins/accelerated-mobile-pages/templates/custom-amp-content-
  • button.js
  • /wp-content/plugins/accelerated-mobile-pages/languages/how-to-use-a-pot-file.txt
  • /wp-content/plugins/accelerated-mobile-pages/LICENSE

The series of requests came from web servers in several different locations around the world and from Chinese telecom providers.

According to data from abuseipdb.com, others had requests of the same type several days before.

That brings us to a rather stunning claim made today by Samuel “Otto” Wood, who is one of the six members of the team running the WordPress Plugin Directory, the person in charge of the moderation of the WordPress Support Forum, the “WordPress.org Admin”, and an employee of Matt Muellenweg. He wrote this in a reply to someone complaining about how the closure of a plugin was handled:

To everybody else: most of the time when a plugin is delisted, it is not for a security issue. Taking pre-emptive measures like removing the plugin just because it was delisted is never really necessary.

Someone taking pre-emptive measures related to AMP for WP – Accelerated Mobile Pages could have avoided being hacked, while Mr. Wood and others on the WordPress side of things left them open to being hacked by not making the new version that fixed the vulnerability available in a timely manner.

This isn’t the first time recently Mr. Wood has at best been unconcerned about protecting websites from being hacked due to vulnerabilities in WordPress plugins. Numerous websites recently were hacked due to a vulnerability in the plugin WP GDPR Compliance, one that was already fixed at the time of the mass exploitation. What could have helped to protect a lot of those websites would have been to force out the update, which didn’t happen. Mr. Wood is seemed to not even consider that things should be changed when it comes to handling force updates in light of what happened there and didn’t respond to our challenging that view.

If you want to go further back over two years ago a reply of ours to him on the WordPress Support Forum related to the poor handling of unfixed plugin vulnerability was deleted instead of him being able to discuss why he and others on the WordPress side of things were leaving websites open to being hacked instead of even considering changing course to avoid that.

It is truly hard to understand what could possibly being going through the minds of the people on the WordPress side of things as they continually refuse to be willing to even consider that things are amiss. What makes this so unfortunate is that fixing the problems on their end wouldn’t be hard, it just takes a willingness from them to work with others, like us, to get them fixed.

29 Nov

Report This Theme Feature of WordPress Theme Directory Doesn’t Seem to Lead To Appropriate Action When Security Vulnerability Reported

What has long seem to us to be an obvious issue with the WordPress Plugin Directory is a lack of any mention of how to report security issues in plugins or a method to do that reporting, on the pages for plugins. For the people on the WordPress side of things that doesn’t seem to be obvious even though moderators repeatedly tell people reporting those through the forum that they shouldn’t be doing that (a lack of ability to conceive that what they are doing isn’t working seems endemic among the people on the WordPress team and has lead to serious issues, like websites being unnecessarily hacked). Interestingly after running across a vulnerable WordPress theme, Hueman, a couple of weeks ago we noticed that the Theme Directory actually has that sort of thing.

On the theme’s main page is button to “Report this theme” on right hand sidebar:

Clicking that brings up this page:

The categories of issues seem like they could use some improvement, as we weren’t sure what “Hacks” refers to, so we filed our report as a “PHP/Javascript Issues”.

Two weeks after we reported this theme for having that security vulnerability, the theme is still available and a new version was released on the 25th, which still contains the vulnerability. So it appears that appropriate action has not been taken in response to that report, which is in line with the poor handling of the security of plugins in the Plugin Directory by the WordPress team, but all the same, it is disappointing.

20 Nov

The Importance of Catching Serious WordPress Plugin Vulnerabilities Early

Last Friday we discussed a remote code execution (RCE) vulnerability that we had caught being introduced into a plugin through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. In that we noted that we couldn’t recall having the check that caught that having flagged any possible vulnerabilities before. So in looking at changes being made to plugins yesterday it was surprising for us to see that code being added to three more plugins was flagged by that check, but it turned out to be a good news situation.

Those three plugins were more plugins by the same developer as the one that was flagged last week (Feedback Form – Collect Vital Information, Free tools to engage your customers, and Feedify:Free Web Push Notifications) and while they were adding the almost the same code that had been added to the plugin we found had a vulnerability last week, the difference from the previous code is that additional code been added before the code flagged by our check is run, which prevents there from being a vulnerability in those plugins. If we hadn’t caught that first plugin then even more plugins and more website would have become susceptible to a serious vulnerability.

By comparison, earlier today we mentioned another security company that claims to have sat on a serious security vulnerability until after it was fixed due to others noticing it six months later and after a connected vulnerability might have already been being exploited.

20 Nov

CEO of Security Company Alertot Claims the Company Left Websites Running WP GDPR Compliance to Be Hacked

When it comes to the response from the security industry to the exploitation of a vulnerability in the WordPress plugin WP GDPR Compliance things keep getting worse. You would think that telling people to update the plugin after it was already widely exploited instead telling them truth they should be keeping their plugins up to date at all times (which would lessen the need for their services) or lying and telling people that your service covered them when it didn’t, would be bad enough. But while looking into something related to another possibility vulnerability that had been in that plugin we came across as post from the CEO, Claudio Salazar, of a security company we had not heard of before, Alertot, who claimed this about the other serious vulnerability that definitely had had been in the plugin:

We have been monitoring this plugin for some months because we discovered a serialization bug around May and added it to our private vulnerability database at alertot.

He could be lying about that, but assuming that he isn’t, he makes no claim of trying to notify the developer of the issue, so it would seem that this company left people open to be hacked and now is trying to market themselves off of that, which is awful, but unfortunately par for the course in the security industry.

Making this worse, the government of Chile has provided them with funding. It would be great if governments were working to improve security instead of working against it by doing things like helping unethical security companies like this.

19 Nov

The Data in the WPScan Vulnerability Database Is Definitely Not Confirmed/Validated

Among the many lies told by the company behind the very popular WordPress security plugin Wordfence Security, Defiant, one that really stands out to us personally is a lie they told that relates to something that as far as we are aware we uniquely do when it comes to collecting data on vulnerabilities in WordPress plugins. In response to a complaint about the data they use in trying to tell people if an update to a plugin is a security update they claimed to rely on “confirmed/validated” data for that. In truth their source, the WPScan Vulnerability Database, explicitly notes that they haven’t verified the vulnerabilities in their data set. As far as we are aware we are the only ones that actually do the work it takes to confirm and validate vulnerabilities, which provides our customer with higher quality data and doesn’t leave them unaware that vulnerabilities haven’t actually been fixed. We recently ran across an instance of where the WPScan Vulnerability Database clearly didn’t do that work, where we had at first thought that maybe we had missed something that we should have noticed.

Back on October 29 we wrote a post detailing an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin AMP for WP – Accelerated Mobile Pages, which had been fixed, but the plugin was closed on the Plugin Directory, so it wouldn’t have been easy to update to a fixed version (though we were available to help our customer do that). Then on November 5 we noted that hackers look to have already started probing for usage of the plugin, which was a concern since the plugin still had not been restored to the Plugin Directory.

It wasn’t until November 13 that he WPScan Vulnerability Database had added a listing that appeared to be related to that:

What was different is that they are claiming that this involves “Unauthenticated” vulnerabilities. That could potentially be of much more concern, since the number of attackers that would be able to authenticate, that is log in to WordPress, would be much smaller than could access websites using the plugin, so depending on what they could do that could be a bigger issue. What it was they were claiming was at issue, was clear as mud since there were zero details provided. So had they found something we missed or did they just publish inaccurate information and have no idea if it was accurate? If you look at the listing you can see it is not “Verified”, so it seems possible they had no idea if the information was accurate (we can’t recall every running across a listing where it was listed as being verified).

In looking at some information for another post or two, we came across an answer, the vulnerabilities they are referring to are all ones that are claimed to require authentication. The person they cite as the source of these vulnerabilities wrote this when notifying the Plugin Directory about the issues:

All this can be done with merely a WordPress subscriber/visitor/commenter account.


These hooks lack nonce and current_user_can() verifications, and wp_ajax_* actions only require the user to be logged in.

That is a good reminder that if they you are looking to keep track of vulnerabilities in WordPress plugins you use, our service is really worth since the WPScan Vulnerability Database was not only providing inaccurate information, but it took them two weeks to even get around to providing inaccurate information. By the time they did it looks like hackers might already have been trying to exploit this plugin for over a week.