Don’t Get Caught With Plugin VulnerabililitesWith our Plugin Vulnerabilities service you are alerted if you any of the WordPress plugins you use contain a security vulnerability.
Search This Blog
- It’s Scary How Little Wordfence Knows About Security
- Questionable Support Advice on Dealing With Hacked Websites From WordPress and Norton Safe Web’s Mystery Blacklisting
- Automattic Helping Security Companies Peddle False Narrative of Brute Force Attacks Against WordPress Admin Passwords
- WordPress Also Disappeared a Support Forum Post That Just Thanked Us
- WordPress Disappears Our Response To Post Indicating that Wordfence Premium Failed To Protect Websites From Being Hacked
Web Software Updates
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: WordPress
Questionable Support Advice on Dealing With Hacked Websites From WordPress and Norton Safe Web’s Mystery Blacklisting
One of the things we do to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service is to monitor the WordPress support forum for threads related to them. In addition to threads that actual relate to that issue, we frequently run into to other security related threads. In doing that we noticed that in many threads a reply containing the same advice is given, which consisted mainly of a series of links. Some of the pages linked don’t seem to provide the best information, so we wondered if the various members providing that reply were actually aware of what they were linking to or if they were just repeating something they had seen others saying. While looking into another issue involving the forum we found that the source of the message was from a series of pre-defined replies for moderators.
While looking into another thread that came up during that monitoring of the forum we came across evidence that one of the links they include, a link to something called Sucuri SiteCheck, may not be the most appropriate to include. In that thread the original poster had written:
Sucuri is showing my site as harmful and is asking for $16/month to fix it, yet my site seems fine, traffic is normal and I have no log in / access problems on any browser or device.
When we went to look to see why Sucuri was claiming the website was harmful, the SiteCheck page was light on details and high on pushing you to use their service:
Looking at the other two tabs of information, the only issue that they were identifying was that website was blacklisted by “Norton Safe Web”:
It seems to us that a service would be careful in situation where they are not themselves detecting anything malicious, but Sucuri seems to be labeling the website as “Site Potentially Harmful” and “Site Likely Compromised” based only on the fact that Norton Safe Web was blacklisting it. Based on our limited experience with Norton Safe Web, that would seem to not be appropriate because the results we have seen from it in the past have been rather poor.
Looking at what they are claiming to have detected with this website makes us more confident of the position.
Here is what they are reporting as of now:
You can see they are not claiming that there are any “computer threats” or “identity threats”, just an “annoyance factor”. What the “annoyance factor” isn’t really further explained, with the only information being that a page is listed as having a “SWBPL” threat. There is no explanation what a “SWBPL” threat is either on the page or through a link. In searching around to try to find out what that is, we found that we were not alone in trying to figure that and that even some people at Norton did not know what it is. The most detailed information we could find was in a thread on the Norton website, where it was stated that:
SWBPL is one of the threat type in safeweb which is based on telemetry which we collect from 3rd party vendor feeds. Since these sites are classified based on the static data it is pron to few FPs
So Norton is apparently warning about the website based on unidentified third-party’s data, which is also apparently prone to a “few” false positives. That doesn’t really seem like something that should be the source for Norton warning about a website and certainly shouldn’t be used by someone else to make claims as to the security of the website.
Looking at the URL they identified as being a “SWBPL” threat, visiting it normally just returns a “Page not Found” message and when visiting it in some other ways didn’t produce any different result. Without having access to the backend of the website we can’t rule out there is some issue with it, but from the outside there is nothing we could find harmful about it.
We hope that WordPress will review the boiler plate message they provide to those with questions about hacked websites and consider if they are providing the best information in it.
Automattic Helping Security Companies Peddle False Narrative of Brute Force Attacks Against WordPress Admin Passwords
Last week we looked at one example of the poor state of security information surrounding WordPress, security companies falsely claiming that brute force attacks against WordPress admin passwords are happening (and also offering products and services that are supposed to protect against that non-existent threat). That has negative impact on security since you end with a lot focus and concern on something that isn’t actually threat while other issues, like the poor state of WordPress plugin security, which actually leads to websites being hacked, don’t get the focus and concern they should and needs to get.
While security companies being part of the problem isn’t something that really surprises anymore, considering that most of them seem to either know and or care little about security, when other companies that you would expect to be better, are part of the problem, it is surprising to us. That brings us to the company closely connected to WordPress, Automattic, which has among their offerings the plugin Jetpack.
Despite the fact that brute force attacks simply are not happening, protection against them is prominently advertised feature of the Jetpack plugin. As can be seen on the plugin’s page on wordpress.org:
and on the features page on the plugin’s website:
It easy to think the public would be more likely believe that they were happening when they see that.
At the same time the Jetpack website provides further confirmation that brute force attacks are in fact not happening. Going back to our previous post, with a password made up of numbers and letters (upper case and lower case) that is six characters long, there are over 56 billion possible combinations. By comparison according to the website, Jetpack has only blocked over 1 billion attempts:
Jetpack has blocked over one billion malicious log-in attempts aimed at our users’ WordPress websites.
While that might be enough attempts for a brute force attack to succeed if they all occurred on one website, that is a cumulative total across possibly millions of websites and maybe for a period of over a year, so it shows that there are not even close to enough attempts for brute force attacks to be happening.
We hope that Automattic will become more consciousness of the impact they have on the security of WordPress going forward, because it would be a help to us and others that are trying to improve the situation.
Recently we have discussed about how someone (or someones) at WordPress is disappearing some of our posts from the their support forum, including an instance where the original poster was left with only bad information from a forum moderator, while our post with the solution to their issue was deleted. Why they are doing that is a mystery, but the end result is that public is left without important information like in that case. While looking over the most recent round of this we noticed that whomever is doing this feels the need to hide what is going on from the public by deleting not just our posts, but in one case deleting a benign response from someone else thanking us, which would have made it obvious that our post was removed if that response remained.
Before we get into the details of the disappeared posts, it worth noting what is supposed to a reason to have a post deleted or edited from the forum:
Generally speaking, posts are only edited or removed where to do otherwise might lead to serious consequences. Previous examples have included posts that accidentally incorporated proprietary code or where the poster asking has reason to fear for their online safety. Having a posted site url come up in Google in NOT a serious consequence. In each case, use your best judgement or ask for a second opinion. If the final decision to to leave the post “as is”, use something like:
When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.
Back in April someone posted on the support forum for the JQuery Html5 File Upload plugin, indicating they were seeing bots checking for the existence of the plugin and wondering if their were exploits to be expected in the plugin. Shortly after they we responded, explaining that the likely cause of this was a false report of a vulnerability in the plugin that was released a week before. The original poster then responded thanking us for the information, “@White Fir Design, thank you for your post!”. Earlier this week as part of the latest purge our post was deleted, though as this screenshot of the changes made shows it wasn’t the only thing deleted (the posts with a red background were removed):
You can see that they not only removed our post, but the response to it. The response couldn’t possibly have lead to “serious consequences” if it remained and there is no “valid legal, security, or safety concern” that could have required it to be deleted. So the only explanation left is that whomever deleted our post wanted to cover up the fact that they were doing that from the public, since if the reply remained it would be obvious that another post by has had been removed.
Among the other posts deleted was another reply about a false report of a vulnerability:
What would be a “valid legal, security, or safety concern” that would require that to be deleted?
In another thread a post was removed were we provided a timeline of a hacking campaign and suggested someone to review the log files for their website to determine the source of the hacking:
Again, what would be a “valid legal, security, or safety concern” that would require that to be deleted?
The final situation we will highlight is a little different, in this case they didn’t delete a whole post, instead they just deleted a sentence mentioning that the people running the Plugin Directory have failed to notice that vulnerabilities still existed in plugins and linked to a page that discussed the problem:
It is quite troubling that someone is trying to sweep under the rug a serious and ongoing problem with WordPress’ handling of security issues in plugins, instead of working on making sure that the problem doesn’t happen anymore.
WordPress Disappears Our Response To Post Indicating that Wordfence Premium Failed To Protect Websites From Being Hacked
When it comes to improving the security of WordPress ecosystem one of the things that is desperately needed is better security information. For example, if you were to look at discussions of WordPress security you would likely to believe that there were a lot of attempts to brute force WordPress admin passwords, despite the evidence from the WordPress security companies claiming they are happening showing that those supposed brute force attacks are not happening at all. Unfortunately, one of the parties we have recently found being an impediment to improving security information that is available to the public is WordPress, or more specially, one or more of the people involved in moderating their forums.
Several weeks ago we discussed how someone at WordPress was disappearing some of our posts on the wordpress.org support forum and it has happened again just in the last day. Since one of the threads that had a reply of ours removed, touches on some important security issues that are in need better information, we thought it would be a good idea to discuss it here, especially since someone at WordPress doesn’t want accurate security information related to that to be accessible to people reading their forum for some reason.
One of the things we do to keep track of what plugin vulnerabilities are out there to make sure we provide the best data for our Plugin Vulnerabilities service is to monitor the wordpress.org support forums for threads discusses such issues. In doing that we run into threads discussing an assortment of other security issues, which we sometimes add a response when we can provide some insights based on knowledge of plugin security and hack cleanups of WordPresw website. Yesterday we ran into a thread involving a claim that several websites were hacked due to a third-party library included with WordPress, SWFUpload.
There we several things that stuck out to with this post. One, was that person, who discussing a hack of several of their clients websites, did not appear to have tried to properly determine how the website were hacked, instead they just seem to be guessing that it was caused by SWFUpload:
Now I think I found the hackers method, I believe they used “swfupload”.
Any security scan will not show “swfupload” as a danger because WordPress (foolishly) includes these script files for legacy reasons. Apart from that, the files in folder “swfupload” are not needed for current WordPress installs. These are old files and since they are old they are NO longer updated to stop hackers.
Now that I had 2 client websites hacked and malicious files uploaded, I believe that is the weak spot in WordPress allowing the hacker to gain access.
If that were the source of the hackings there should be evidence of the log files, which their post made no mention of reviewing (despite being a basic part of a hack cleanup). It seems highly unlikely that was the source, since if a hacker were to have discovered a vulnerability that allows hacking websites throughWordPress it is likely they would try to hack as many websites as possible quickly before it was discovered that their was issue since once it was, WordPress could quickly release an automatic update that would protect the vast majority of WordPress websites within a day. Seeing as we haven’t seen any evidence to point to a hack of WordPress itself occurring recently, it seem unlikely that was the source. The first two paragraphs (of total a three) of our response discussed those things:
If there was a known vulnerability that could be exploited like this in the version of SWFUpload included with WordPress it is likely that there would be a lot of websites being hacked through it right now, but we are not seeing any evidence of something like that going on at this point, so it isn’t likely to be the source of your hackings.
What you will want to do is to review the log files for the websites to see what evidence they provide as to the source of the hackings. If SWFUpload was in fact the source then there should be evidence of that in the HTTP log and that evidence would also provide information needed for the WordPress developers to work on fixing it.
The other major thing that stuck out what this person surprise that the website had been hacked while using the Wordfence Premium service:
I had 2 of my client WordPress sites hacked in this past month and they uploaded malicious PHP and JS files to infect the site with a backdoor PHP script. When I found the hacked upload 2 weeks ago in one client’s site, I wondered how did they got into the site while using WordFence Premium?
Should that be surprising? Not to anyone who is actually knowledgable about security, since in reality the various website security products and services out there provide at best limited protection against real threats against websites (and sometimes they actually are the security threat). For example, a WordPress security plugin would have no ability to stop an attacker who gains access to the FTP credentials from accessing the website’s files and in fact if the attacker wanted to they could modify the security plugin to ignore any changes they made to the website.
For Wordfence in particular it wasn’t surprising to us that their service wouldn’t protect a website considering among other thing they are one of the security companies pushing false claims of brute force attacks (while advertising that their service will protect you from them) and that we recently found their claim that their plugin would protect against stored XSS vulnerabilities was not supported when testing real world vulnerabilities against it. When it comes to their paid service, Wordfence Premium, back in June we noted that it was failing to detect vulnerabilities that were being exploited in the current versions of plugins. We concluded our response by mentioning that, since it is relevant for someone thinking that the service would protect them, that said service is oblivious to vulnerabilities that are being exploited and could actual be a cause of the hackings:
Since you brought up Wordfence Premium, it is worth noting that the service looks to have missed detecting exploitation of numerous vulnerabilities that were in the current version of WordPress plugins, so its ability to protect websites against real world threats is at least somewhat limited.
Was someone at WordPress trying to cover up the fact that Wordfence Premium has serious problem in its protection by removing our response, we don’t know, but removing our post had the same effect.
We were recently brought in to deal with a WordPress website that had been hacked multiple times and just re-hacked. In that type of situation one of the first things that should be done is to review the log files available for the website, since those are likely to provide evidence on how the website is being re-hacked and depending on how far the logs go back, how the website was originally hacked.
One of the big problems we find in being able to review the log files of a hacked website, is that often times web hosts only store the log of HTTP activity for a short period, in some cases less than a days worth of logging is available. One of the better web hosts when it comes to this is GoDaddy. With their standard web hosting accounts using their own control panel, they store about a months worth of logging. When using the cPanel control panel instead, the log is stored for a shorter time period by default, but you can enable archiving, so we can at least make sure it stored for a longer period once we get started on the cleanup.
The website we are dealing with in this case though was in GoDaddy’s Managed WordPress hosting account, which we would find out when the client tried to get access to the log files, does not provide any access to the log files. We are puzzled that they manage to provide that in the standard web hosting accounts, but not not in what would seem to us to be a higher end type of account. The explanation for why they can not provide it, is also puzzling, as they say they can’t provide it because the website is hosted in a shared environment. The other web hosting accounts are also on shared environment and yet they manage to provide them there.
If you are concerned about security we would recommend that you not use their Managed WordPress hosting until they resolve this, since if you were to get hacked, you are going to be missing important information needed to properly clean it up (is worth mentioning that many companies that do hack cleanups either don’t know how to do things properly or are cutting corners and don’t review the log files like they should).
While we were looking over the marketing materials for the service we noticed some security claims that are also worth mentioning. One of the “key features” of the service is that they “keep the bad guys away”:
Seeing as the website we are dealing with got hit multiple times while using this hosting service, their ability to actually protect the websites is is at least limited.
The ability to protect the website is also contradicted by another feature available in one level of account, which removes malware from the website:
If they were actually able to protect the websites, as they advertise, then there shouldn’t be any malware getting on the website that needs to be removed.
We would also have wondered about the fact that the company SiteLock would be involved in doing hack cleanups on this service, when they can’t do things properly because the logs are not available, if not for the fact that we have seen that SiteLock doesn’t seem to seem to be interested in properly cleaning up websites and is known for taking advantage of their customers.
When it comes to security companies, trustworthiness is critical, since the average person isn’t going to have the knowledge and skills to understand if the security company is actually doing (or could even possibly do) what they are claiming to do to protect them. Any upstanding security company would therefore be very careful in what they say and do, so if you see a company being less than honest it should be a major red flag when it comes to using their products and services.
That brings us to something we noticed in the WordPress security plugin iThemes Security. When you install the plugin a notice is displayed at the top of pages in the admin area that read “New! Take your site security to the next level by activating iThemes Brute Force Network Protection”
If you get click the “Get Free API Key” button in that notice you get shown the following page:
On that page they accurately describe what a brute force attack is, so clearly they know what it is. What they either don’t know or they are intentionally not telling people is that brute force attacks against WordPress admin passwords are not happening, so you are not taking your site security to the next level by enabling that feature as they claim.
What makes this more troubling is that they are using the non-existent threat of brute force attacks to try to collect users’ email addresses. By default permission to send “email updates about WordPress Security” is also included when doing that and considering in the best case here they are not aware of it pretty basic security fact that brute force attacks are not happening, the quality of the security information they would provide in those email is likely to be poor.
Just based on this it would seem like a good idea to avoid this company and their plugin, but it isn’t the only issue with found with the plugin recently. Back in April we ran across the fact that the plugin had button labeled “One-Click Secure” that didn’t do anything.
When it comes to improving the security of the WordPress ecosystem one of the biggest problems we see is the shear amount misleading and often times false information that is put out by security companies. One of the most frequent falsehoods we see is the claim that there are a lot of attempts to brute force WordPress admin password. Not only is the claim false, but is so obviously false that these security companies either don’t understand the basics of security or they are knowingly lying to the public, either of which would be a good reason for you to avoid them.
To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:
- 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
- 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
- 10 characters long: Over 839 quadrillion possible combinations (839,299,365,868,340,224)
- 12 characters long: Over 3 sextillion possible combinations (3,226,266,762,397,899,821,056)
Now that you have an idea of the number of requests it would take to actually do a brute force attack, lets look at the number of attempts that security companies are claiming are occurring that support their claim that brute force attacks are going on.
First up is Wordfence, back in January they put out a post about the claim that brute force attacks are going on and gave a figure for how many login attempts had occurred over a recent 16 hour period (they call each login attempt an attack):
During this time we saw a total of 6,611,909 attacks targeting 72,532 individual websites. We saw attacks during this time from 8,941 unique IP addresses and the average number of attacks per victim website was 6.26.
The total during that time period likely isn’t any where near enough login attempts for even one brute attack to be successful, but with less 7 attempts per website, that clearly is not evidence of brute force attacks actually occurring.
How about Sucuri Security, they have a page on their website entitled WordPress Brute Force Attacks, that is supposed to present the “state of brute force attacks against WordPress sites”. The graph shown there includes failed login attempts for websites “protected” behind their website firewall. There is an obvious issue with that since failed login attempts are not necessarily malicious, so the graph is not necessarily entirely that accurate. Even with that caveat, the largest amount on one day looks to be have been about 50 million requests:
We don’t know how many websites that is split across, but even if it was one website that likely wouldn’t be nearly enough for one successful brute force attack per day.
In one instance recently, someone we perviously did some work for contacted us because they had gotten an email from Sucuri’s WordPress plugin that was alerting them to brute force attack. In that instance Sucuri was claiming that a brute force attack was occurring based on a total of 30 login attempts.
Security Companies That Don’t Understand the Basics of Security
Back in September of last year Sucuri not only claimed that brute force attacks where happening, but also claimed that brute force attacks are frequent source of hacking (despite the fact that they are not actually happening at at all):
However, brute force attacks are still going strong. In fact, they are one of the leading causes of website compromises.
So what could explain the false claims about brute force attacks?
One explanation is that these security companies don’t have an understanding of the basics of security, like knowing what a brute force attack is. Considering you don’t have to look at some obscure resource to know what they are, you just have to go to the Wikipedia, there isn’t any excuse for that.
The other explanation is that these security companies do know what a brute force attack actually is, but they are lying about them happening since if they told what was actually happening they wouldn’t be able to use it to push the products and services they provide. That would have the added bonus of allowing them to claim they can protect against something, without having to worry about that turning out to not be true (as we recently found with another claimed protection by Wordfence), since the brute force attacks are not actually happening.
Protecting Yourself From the Real Threat, Dictionary Attacks
So based on those security company’s data brute force attacks are not going on, but there are malicious login attempts happening, so what is actually happening? Based on looking at actual login attempts and the number of requests it looks like most of the malicious login attempts are from dictionary attacks.
A dictionary attack involves trying to log in using common passwords, think things like “123456” and “123admin”.
With dictionary attacks protecting your website is really easy, just use a strong password. Thats it. You don’t need to put in place all sorts of other protection, since the dictionary attacks will fail as long as you do that. WordPress now defaults to generating a strong password and displays a password strength indicator if someone chooses to create their own password, so if you have an Administrator choosing to use a weak password, you probably have bigger issues to worry about. If you are concerned about lower level users using weak passwords and then being subject to dictionary attacks, there are a number of options to enforce stronger passwords that are available.
With it being that easy to prevent what is going on, it would be difficult for security companies to promote products and services to deal with this, so that is why we wonder if they are intentionally lying about what is going on.
It also worth noting that there is likely a quite a bit of overlap between the passwords tried during different dictionary attacks, so the amount passwords tried is likely much less than the total attempts occurring over even a fairly short period of time.
Help Us Clear Things Up
If you see someone claiming that brute force attacks against WordPress admin accounts are happening, we would appreciate if you point them to this post, so that we can start to clear up the false information being pushed by those security companies and people can start focusing on properly protecting themselves.
As part of the work we do for our Plugin Vulnerabilities service we monitor the WordPress.org support forum for threads about security issues in plugins, to help make sure that we can provide the best data on plugin vulnerabilities to our customers. That also causes us to run across an assortment of related topics. When we can provide some insight we also will reply to threads we run acrros. In the past few days we have been finding some of our recent replies have started to disappear (if you were to go to the relevant threads you wouldn’t even known they had been there) without explanation. We really don’t know why that might be, the more concerning possibility is that they didn’t like that in one thread we had corrected some inaccurate information in regards to the state of handling of plugin vulnerabilities by the Plugin Directory, but since there is no explanation we have no idea what the cause iss. These disappearance don’t just impact us, it has also caused others to be left without useful information.
Take for instances a thread we responded to yesterday. Someone started a thread looking for help identifying an arbitrary file upload vulnerability in some software running on their website. Seeing as arbitrary file upload vulnerabilities are probably the most serious vulnerability out there in plugins, since it is the most likely to be exploited of commonly found vulnerabilities, we thought it would be a good idea to see if we could find any in the plugins they indicated they were using since we would want to make sure that is in the data our Plugin Vulnerabilities service. In checking over the plugins we couldn’t find any of that type of vulnerability.
While we were already looking over things we thought we might as well see if we could take a look at the Suffusion theme they were using as well. The theme used to be available on the wordpress.org Theme Directory, but was removed a month ago. Since it still remains in the underlying repository we were able to get a copy of the last version, 4.4.9, of that and found that was in all likely hood the source of the issue the original poster was having, as the AJAX accessible function suffusion_admin_upload_file() in the theme allows anyone logged to upload files through the WordPress function wp_handle_upload(). That function only allows certain types of files to be uploaded, so it wouldn’t be an arbitrary file upload vulnerability, but the logging included with their post showed that files that were uploaded are types that are allowed by that. Notably the logging included with the post did not show any .php files being uploaded, which is what an arbitrary file upload vulnerability would normally be used to upload. The request for doing the uploads through theme would be handled through a POST request to /wp-admin/admin-ajax.php, several of which are shown in the logging that was included in the post.
We posted reply explaining that and it then quickly disappeared. In the meantime the only other person that responded was a forum moderator, who was sending the original poster off in the wrong direction by telling them to contact their web host about server issues. None of the evidence provided looks to match a server issue to us, so we are not sure why they would suggest that. Making the whole thing more aggravating, after we had already posted what the actual cause was (and then having it disappear) the forum moderator posted that beyond what they told the person about focusing on a server issue, “There is little else anyone can say.”, which clearly isn’t true.
Through the work we do for our Plugin Vulnerabilities service we spend a lot of time on the Plugin Directory, dealing with issues in plugins on it (mostly security issues), and interacting with the people running it. Our experience is that things are not really handled well by the people running it. Something we ran across today seems like a good example of the poor state of the people managing it, which we thought would be good to share to help expose the bad state of things.
Since we have several plugins in the Plugin Directory, prior to the release of a new version of WordPress we get an email asking us to test our plugins with compatibility with the new version of WordPress and then update them to indicate they are compatible with the new version. Here is the email we got prior to 4.5 (the plugin listed as only being tested up to 3.6 is due to the fact that the plugin’s functionality was integrated into the next version of WordPress):
WordPress 4.5 is scheduled to be released on April 12. Are your plugins ready?
After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.5. This information provides peace of mind to users and helps encourage them to update to the latest version.
Here are the current “tested” values for each of your plugins:
* https://wordpress.org/plugins/automatic-plugin-updates/ (tested up to 4.5)
* https://wordpress.org/plugins/https-updates/ (tested up to 3.6)
* https://wordpress.org/plugins/no-longer-in-directory/ (tested up to 4.4)
* https://wordpress.org/plugins/plugin-vulnerabilities/ (tested up to 4.5)
For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.
Looking to get more familiar with 4.5? Check out this roundup post on the core development blog: https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/
Thank you for all you do for the WordPress community, and we hope you will enjoy 4.5 as much as we do.
WordPress core contributors
So clearly the Plugin Directory wants people to be testing their plugins for compatibility and then updating the compatibility information.
Based on that you would think that the person described as the “WordPress.org Tech Dude”, who is involved in managing the Plugin Directory, would be setting an example by making sure to do that, but as we noticed today that isn’t the case. For one of their plugins PHP Code Widget, which has 100,000+ active installs, it is still only listed as being compatible up to WordPress 4.4. WordPress 4.5 was released in April and WordPress 4.6 getting closer to release, with the third beta released a week ago.
It isn’t a situation where the plugin is no longer supported, hasn’t been tested, or the developer just forgot to update the compatibility. As a couple of forum threads show, the developer is instead just refusing to update the compatibility listing. If that sounds strange to you, you are no alone, but that is inline with the type of attitude we have seen when dealing with those people.
SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services
When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:
This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside 🙂
Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.
What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.
One review reads:
If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.
That seems like reasonable complaint, which gets this response from the developer:
free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.
As part of their response to another review the developer wrote in part:
If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.
It is also worth noting that there are a lot of rather fake looking reviews for the plugin.