One of the many problems we see when it comes to improving the security of websites is that it easy for companies to make it sound like they are doing impressive things in regards to security when they are doing very little or even doing things in way that put their customers at risk.

Recently we ran across an example of that involving the web host SiteGround, which was touting their quick response to a WordPress plugin vulnerability in a blog post:

Тoday, a serious vulnerability issue with one of the vastly used Yith plugins – the WooCommerce Wishlist was discovered by Sucuri. The latest plugin version – 2.2.0 patches the vulnerability but all versions prior to it are at risk. To protect our customers, who haven’t updated their plugin, our security team started working immediately and a WAF rule was just applied on our servers.

We’re very proud of our internal WAF (Web Application Firewall) system that protects all SiteGround shared and cloud servers. It allows us to dynamically add different rules across our network and block hacking attempts. The moment we got notified about the issue with YITH WooCommerce Wishlist plugin, our security team started working on the case. We’ve managed to come up with a rule, that shields you against potential attacks utilizing this vulnerability. Although this does not patch the problem in its core, we’ve added protection against those, who try to utilize it. This said, we urge you to update to the latest plugin version, which includes the official patch for this vulnerability.

As we will get to in a second this really isn’t all that impressive, but based on the comments on the post, others thought so.

That post was written on January 17, which was six days after the vulnerability was fixed. If a hacker had been interested in the vulnerability they likely could have already been exploiting shortly after it was fixed, considering that it should have not been hard to figure out what it was based on the changelog entry for it:

• Fix: fixed security vulnerability, causing possible SQL Injections (huge thanks to John C. and Sucuri Vulnerability Research team)

That is one of a number of reasons it would be much better for people to be keeping their plugins up to date then rely on a WAF for protection. Another one that is important to consider, is that the protection like that may not work all that well, as we and others have found that type of protection can be rather limited in what it stops. We have yet to see any WAF providers that provide results from testing, much less independent testing, that their WAF is effective at protecting websites from real threats (despite that seeming like it should be a baseline requirement for anyone considering paying for such a product/service). By comparison, since vulnerability fixes are public there is at least the chance that others will have checked over things. While that doesn’t always happen, it does happen enough to regularly lead to further improvements to protection against those vulnerabilities, which likely can’t be said about those WAFs.

What is the much larger issue here though, is that this was the only vulnerability they made an announcement about providing protection for last month. That is rather underwhelming when you considering that we added data on 44 newly disclosed vulnerabilities to our data set last month, including 11 that haven’t been fixed. So why that vulnerability and not any of the other 43?

That plugin is fairly popular, but as people dealing with security of websites should really know, the popularity of a plugin has little role in the risk of a vulnerability being exploited, so that would seem like it isn’t reason (or at least shouldn’t be).

It shouldn’t be the type of vulnerability either, seeing as SQL injection vulnerabilities are not something that in most variants is something that is of much chance of being exploited on the average website.

Instead it looks like there is simple explanation, that vulnerability was the only one disclosed by their security partner Sucuri last month (a partnership that has caused SiteGround customers to be provided false claims that websites are hacked due to SiteLock’s really poor scanner). In fact going back through last year, the only other blog entry announcing protection against a WordPress plugin vulnerability was another one disclosed by Sucuri. Considering that that neither of those was one that is of much concern to the average website and considering that there have been many vulnerabilities that were already being exploited or likely to be exploited, they don’t appear to have to done much for their customers when it comes to protecting against vulnerabilities in WordPress plugins. Unlike SiteGround, we don’t passively wait to be notified about disclosed vulnerabilities, so we can help protect our customers from many more vulnerabilities (we also provide a plugin to handle automatically updating plugins).

In looking over SiteGround’s other recent blog entries we noticed more concerns when it comes to their handling of security. For example, in one post they were touting their “AI-based” supposed prevention of brute force attacks, despite that type of attack not happening. Considering at best that they are misusing basic security terminology, something their partner Sucuri has claimed is a red-flag when it comes to security (though amazingly equally applies to Sucuri itself), it probably isn’t all that surprising that their WordPress plugin, which has over 300,000+ active installs according to wordpress.org, has multiple easy to spot security vulnerabilities.

One of the vulnerabilities is so easy to spot that it was picked up by our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own). We have notified SiteGround of the details of the vulnerabilities and will be disclosing them once they have had a chance to fix them.