Website Security | White Fir Design Blog

Hackers Using Insecure Magento Extensions to Access Magento Admin Login Page Without Knowing Normal Address

While reviewing the log files while cleaning up a hacked Magento website recently we ran across a reminder that a common security practice isn’t full proof. With the Magento software and some other software the software has a built in capability to use a non-standard address for the login page for the admin portion of the website. With other software that is commonly promoted security feature to be implemented with an add-on.

The value of that is limited as while there are widespread claims that there are frequent brute force attacks against admin passwords, in truth what is going on are dictionary attacks, which involved trying to log in using common passwords and that can easily be prevented from being successful by using a strong password. There is the possibility of some value of doing this in a far more limited situation where the hacker has access to valid login credentials for the website, but it turns out that there can be various ways to get access to login page without knowing that address.

In the logs of this hacked website we were seeing many POST requests to this address:

/index.php/magenotification/adminhtml_feedback/index/

When visiting the page we saw that the Magento admin login page was showing. In looking into if that all there was that we found that this is something that hackers are looking around with pages like that generated by various extensions.

Magento added protection against this issue with SUPEE-6788, which was part of Magento 1.9.2.2, but by default the protection is not enabled.

A Web Application Firewall (WAF) is Not the Way to Deal With the Reoccurrence of a Hack of a Website

These days quite a bit of our business dealing with the cleanup of hacked websites is re-cleaning websites after other security companies didn’t clean them up properly before us. Troublingly we recently noticed a company that offers to clean up websites, ASTRA Security, treating that as a normal result and using it to promote using web application firewall (WAF), which they also sell:

Even after clean up and restoring your site, the Magento admin hack may reoccur. The reasons could be a backdoor left by the attacker or simply a vulnerability that may be left unpatched. To avoid such scenarios it is highly recommended to use a WAF or security solution of some sort.

If there is still a backdoor on the website that means it hasn’t been cleaned up, since that would be something would be removed during the cleanup, which someone cleaning up hacked websites should understand.

Part of a proper cleanup is trying to figure out how the website was hacked, so if a vulnerability is left unpatched then things probably have not been done right either.

The providers of WAF’s don’t provide evidence that they provide effective protection against vulnerabilities, while we have seen plenty of evidence that they don’t provide it. It would be even more difficult for them to protect against exploitation of backdoors due to wide variety of their location and what is done through them, which someone cleaning up hacked websites should also understand.

The best way to handle a reoccurrence is to avoid one in the first place by hiring someone like us that will properly clean up the website. If you didn’t do that then the next best solution is to hire someone to re-clean it that will do things properly.

GoDaddy’s Idea of Securing Websites Actually Involves Leaving Them Insecure and Trying to Deal with the After Effects of That

Yesterday we discussed GoDaddy’s usage of misleading claims to try to sell overpriced SSL certificates. Based on that it probably wouldn’t be surprising to hear that they would mislead people in other ways about security and that is exactly what we ran across while looking into things while working on that previous post. When we clicked on the “Add to Cart” button for one of their SSL certificates, at the bottom of the page we were taken to, there was a “malware scan and removal” service offered to “Secure your site”:

The description of that is:

Defend your site against hackers and malware with automatic daily scans and guaranteed cleanup.

It shouldn’t be too complicated to understand what is wrong with that, though as we mentioned earlier today there seems to be a lot of confusion when it comes to what security services and products do.

If a website is secure it wouldn’t have malware or some other hack on it to detect or remove, so either GoDaddy doesn’t understand what they are providing or they are lying about.

The problem we see so often with this sort of service is that people will fail to do the things that will actually keep websites secure because they believe a service like this will actually keep a website secure.

Trying to deal with the after effects of having a website hacked instead of actually securing it introduces a lot of issues. One of those being that if a hacker uses the hack to exfiltrate customer data stored on the website a cleanup isn’t going to undo that.

What is a lot more important to note is that everything we have seen from the underlying provider of GoDaddy’s security services, Sucuri, is that they are not good at detecting and cleaning up hacks of websites. Their scanner seems, to put it politely, incredibly crude. Their employees seem to lack a basic capability to understand evidence that a website is hacked. And in what is most relevant to this specific service, we recently we brought in on a situation where their scanner had failed to detect that a website was hacked and then they repeatedly incompletely cleaned up the website, leaving it in a hacked state for a while. It was only after we were brought in to clean things up properly (which Sucuri doesn’t appear to even attempt to do) that it was finally cleaned and stayed that way.

Monitoring For Malware and Other Website Hacks Won’t Prevent a Website from Being Hacked

In dealing with people with hacked websites we are often reminded that things that seem like they should be easy to understand about security products and services are often not for a lot of people. What plays at least some role in that, and maybe a lot, is that the security industry frequently makes misleading and outright false claims.

We recently had someone that contacted us about a hacked websites who seemed to be unaware that monitoring for malware or other types of website hacks would not prevent the website from being hacked or clean it up if it did get hacked. In their case they said they were relying on monitoring from SiteLock and Wordfence.

What monitoring tries to do is detect evidence of malware or another hack after it has occurred. Since it comes in to play after the hacking it wouldn’t be possible to stop it from occurring. Despite that we have seen providers of monitoring services promote them as being able to stop or protect a website from being hacked. Either these providers don’t understand what they are providing or are lying about it, neither of which is a good option.

If there were monitoring solutions that were effective at doing what they are actually trying to do they might be a good option as additional measure beyond doing the basics for high profile websites that are at elevated risk of being targeted by hackers. We have yet to see any such service that presents evidence, much less evidence from independent testing, that they are effective though, which seems like it should be a baseline for using such a service at all. What we have seen of monitoring solutions and other tools to detect malicious code in years of dealing with the cleanup hacked websites is that they have a limited, at best, ability to spot malicious code on a website.

For the average website what should be the focus is doing the things that will actually make websites secure instead of hoping that a security service is going provide even a fraction of what the extraordinary claims they often are promoted with would lead people to believe they are capable of.

GoDaddy Using Google’s Change to Label Non-HTTPS Websites as “Not Secure” in Chrome To Sell Overpriced SSL Certificates

Yesterday we discussed someone’s belief that their website would be useless in its current form due to a company’s blog post about Google making a change to their Chrome web browser to label non-HTTPS websites as “not secure”. Unrelated to that, yesterday we got sent an email from GoDaddy touting purchasing SSL certificates from them to avoid websites being labeled that way by Chrome. Two things stood out with that. The first being that GoDaddy charges much more than you need to be paying for an SSL certificate, which will in part prevent a website from being labeled as “not secure”, but also that GoDaddy doesn’t seem to really understand what they talking about when it comes to HTTPS. That latter fact isn’t all that surprising considering GoDaddy’s poor security track record.

The subject of the email was “Your customers need SSL on their sites ASAP.”.

On the page linked to from the email, their lowest end SSL certificate, which would be the level you need to avoid the “not secure” label, the introductory price is 60 dollars if you pay for two years upfront and then after that 75 dollars:

With other providers you can pay a fraction of that price. It also looks like that used to be true with GoDaddy as well, as they have apparently significantly increased the prices they charge for SSL certificates over the years despite nothing that would have increased their costs.

Using Let’s Encrypt you can even get a free SSL certificate and there are plenty of web hosting providers that have the capability integrated into their control panels to allow setting those up. It’s worth nothing that GoDaddy’s security company has been a major sponsor or donor to Let’s Encrypt, which seems like a tacit endorsement of Let’s Encrypt .

That GoDaddy is overcharging for SSL certificates instead of being like other hosting providers and offering free SSL certificates seems worse to us when reading one of the three testimonials they chose to show on that page that touts them providing an affordable solution:

I received a call from product support to let me know Google was getting more rigid about “secure sites”. We were able to make the upgrades that I could afford, and make my site more mobile accessible AND secure.

Another testimonial seems more insidious since it gives the impression that GoDaddy is providing cheaper certificates than others instead of more expensive ones:

I’ve set up SSL certificates from various companies but will never use anyone but GoDaddy every again. It’s easy to set up, great support and at a fraction of the price it’s great all around!

That is a great example of why testimonials are not a great source of information because that one allows GoDaddy to make it seem like they providing a more reasonable priced product without having to lie. If they really were providing cheaper certificates they would have been able to present evidence to back that up.

Misleading Marketing

The email made the following claim:

SSL is not only the right thing to do for your customers, it’s also great for boosting their search rankings and getting more traffic to their sites.

No link was provided that backed up that claim. On the page to purchase an SSL certificate, the claim is made repeatedly in regards to Google search results, but again no evidence is provided.

Based on what Google has said it doesn’t sound like using HTTPS has much impact. Here is in part what Google said when the disclosed that usage was a ranking factor:

We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

As far as we are aware they haven’t announced strengthening it and they seem to be using changes to Chrome to increase usage of HTTPS.

In another instance, a Google employee explained the impact as follows:

If you’re in a competitive niche, then it can give you an edge from Google’s point of view. With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.

Importantly, if both websites were using HTTPS the impact on the ranking boost of either one would be nullified.

Misleading on that seems of less importance than a page they created just to promote buying their SSL certificates due to the change to Chrome.

There they claim that “A Not Secure label on your website can devastate your business.”:

No evidence is presented for that despite it being a serious claim.

What seems like a clear indication that they are not interested in informing people about what is happening, but selling something is another part of that page which states that using HTTPS will “shows visitors they’re safe with the little green lock in their address bar”:

The next HTTPS related change in Chrome, occurring in September, involves it downgrading what is shown for HTTPS pages:

Do They Know What an SSL Certificate Even Is?

Going back to the page for selling SSL certificates there is what is supposed to be an explanation of how a HTTPS connection works, but it seems to have been written by someone that isn’t familiar with it all:

An SSL certificate doesn’t “automatically creates a secure, encrypted connection with their browser”, instead the SSL certificate is just used to validate that a secure connection is being made with the intended website instead or with another party.

Among the other issues with that is that the level encryption is determined by the server and the web browser, not the SSL certificate.

GoDaddy might be able to justify a higher price for an SSL certificate if good customer service was provided, but considering how off the marketing material is, it is hard to believe that their customer service would be well informed about them.

Sucuri’s Website Application Firewall (WAF) Makes Improving Websites’ Security Harder, While Being Easily Bypassable

When cleaning up a hacked website there are three main components to doing that properly. We often find that security companies don’t do two of those. One of them being trying to determine how the website was hacked. The other being getting the website secure as possible, which usually involves getting the software on the website up to date. If a company isn’t able to make sure the software is up to date, it seems likely they also are not familiar enough with the software that they should be dealing with hacked websites running it.

One well known company that usually skips doing those things is Sucuri. They promote as alternative to doing that securing, that you can rely on the virtual patching provided by their website application firewall (WAF). There are a number of reasons why that is bad idea, including that they don’t present any evidence, much less from independent testing, that their virtual patching is effective (they also don’t present any evidence that their service is effective at protecting websites in general). Probably the largest problem with relying on that though, is that it can be incredibly easy to go completely around their WAF, leaving websites that haven’t been properly secured wide open to being hacked.

Before we get in to that, what lead to us writing this post was our recent experience with their WAF making it harder to get a website secured.

We were recently brought in to upgrade a Joomla installation on a website that Sucuri cleaned but had failed to upgrade the software on it. When we went to do that upgrade we ran into an error, “ERROR: AJAX Loading Error: Forbidden”:

That error message doesn’t provide much information on what was going wrong and we would guess that others that run into it might get stuck at that point. In debugging that we found that when an AJAX request was made to /administrator/components/com_joomlaupdate/restore.php the response being received was this page:

At that point we could have contacted the person we were dealing with from the website and get them to try to whitelist our IP address, but there was a far quicker solution, simply bypassing Sucuri’s WAF, which can be incredibly easy to do.

Here’s is how Sucuri explains how their WAF works:

The reality is that all HTTP/HTTPS traffic does not have to begin where they show it beginning in that graphic, instead, if you know the IP address of the Original Host you can connect directly to it, bypassing the WAF entirely.

While in something we will get to in a moment, Sucuri refers to this IP address as being “hidden”, in reality it often isn’t hidden at all. In the case of the website we dealing with we just pulled up the DNS records for the website and the second IP address (after the Sucuri one) was the Original Host’s IP address (there was another equally easy method available as well). By simply associating that IP address with the domain name in a computer’s host file the Sucuri WAF can be bypassed.

From previous real world experience we can say that people will in fact rely on Sucuri’s WAF to keep them safe instead of keeping software up to date, which can leave people wide open to attack if someone just takes time to bypass the WAF. What makes that particularly problematic is that a website could appear to be secure for a long time, leading to people claiming that Sucuri’s solution is effective, and only later it becomes clear that things were not as how they seemed.

Here’s what makes this even more troubling, Sucuri is aware of the ability to bypass their WAF, but they either don’t understand that their attempt solution to stop that doesn’t resolve the issue or they don’t care that that what they are providing is fundamentally insecure.

The page Prevent Sucuri Firewall Bypass on Sucuri’s website begins:

If someone knows your hidden Hosting IP address, they can bypass our Firewall and try to access your site directly. It is not common or easy to do so, but for additional extra security, we recommend only allowing HTTP access from our Firewall.

The best way to prevent hackers from bypassing our Firewall is limiting their access to your web server. To do this, all you have to do is add restrictions to your .htaccess file so that only our Firewall’s IP will be able to access your web server.

As we already noted, the IP address isn’t necessarily hidden at all. Calling attempting to prevent the easy bypass as “additional extra security” as opposed to being essential, doesn’t provide much assurance that they actual are concerned about the security of websites using their service.

The larger issue here is that trying to restrict what IP address can access the Original Host directly isn’t very effective. That is because all someone has to bypass that restriction is to spoof a permitted IP address, which involves making it seem a request came from a different IP address than it really did. Either Sucuri doesn’t understand that or doesn’t care that their WAF is fundamentally insecure, neither of which should be true about a security company.

Their a major limitation with spoofing an IP address that is important to note though, which is that any response would not be sent back to the system sending the spoofed requests since the response would be sent back to the spoofed IP address. But with the kind of vulnerabilities we see actually being exploited on websites that often wouldn’t be an issue since the hacker doesn’t need to receive a response to gain further access to the website. Oncee they have access they could remove the IP address restriction or send any responses they need in way they can still access (say writing them to a file accessible through the website).

While we wouldn’t recommend using Sucuri’s WAF (or their services in general), if you are using it, restricting IP addresses as suggested in that previously mentioned article would provide better security when using their WAF.

There Should Need to Be Evidence That Security Measures Are Effective, Not Ineffective

When it comes to security advice for websites, there is a nearly endless supply. What there decidedly isn’t is an abundance of is testing or other evidence presented that the measures mentioned in that advice are effective.

That seems particular acute when it comes to advice to use paid security products and services, for which we have frequently see bold claims about their effectiveness in their marketing materials, but we have seen almost no evidence presented as to their effectiveness (when it has, it hasn’t been very reliable, for example, one company claimed to have had independent testing done, when the testing decidedly was not independent).

That brings us to a couple of recent comments on one of the posts on the blog for our Plugin Vulnerabilities service.

We had noted that a lot what is supposed to provide protection doesn’t actual do that and cited our testing to see if WordPress security plugins could protect against real vulnerabilities in other plugins:

A lot of what is portrayed as protecting, including a lot of security hardening, doesn’t actually provide any protection. There is even a term for that type of thing, security theater. That is part of the reason we started doing testing of security plugins against real vulnerabilities, to show what, if any, protection they provide. So far BulletProof Security hasn’t provided any, which is what brought this up in the first place.

The response we got to that was this:

This is a big claim and it is one you would need to back up with some proof, especially given that so many people rely on them to protect their websites. Please point me to articles which back these statements. As a typical web dev customer who spends time hardening sites, and promoting a secure WP service, I’m unconvinced about your claims.

This seems to us to be backwards, the onus should be on proving something actual provides protection. Just because a lot of people are doing something that doesn’t mean that is effective, especially since a lot of people are following advice from others that don’t actual have the experience needed to be a reliable source.

Now in reality we have also written plenty about this sort of thing from years ago when we wrote about how hiding the WordPress version isn’t an effective security measure (this seems to have dropped off as claimed important security step) to the currently very popular, but false, claims that there are a lot of attempts to brute force WordPress admin passwords (which are pushed by security companies that then tell you their product or service is the solution). That second item is also a good example of why evidence is important, because we were actually able to disprove the claim based on the evidence that security companies were presenting as supporting it.

It Looks Like SiteLock is Scamming People

Over the past couple of years we have run across a lot of bad stuff involving the security company SiteLock, from not doing basic security checks to not doing basic parts of hack cleanups to breaking websites they are supposed to be cleaning to labeling a website that is very dangerous for visitors as being “secure”. Unfortunately those kinds of things are really par for the course when it comes to security companies (it is a really sleazy industry in general). But recently we have started to see and hear more that indicates that SiteLock has gone past that and moved to more egregiously cheating their customers. Making this more of a problem, is that they now have partnerships with many web hosts, which gives them additional legitimacy that they shouldn’t have considering the multitude of problems we have see involving them.

One of the issues that we see coming up a lot involves SiteLock charging a monthly fee to protect websites and then when the website gets hacked they want a much larger amount to clean up the website. If the website is getting hacked then the protection being paid for doesn’t seem to be actually happening or isn’t very good. There also seems to be an incentive for the protection they provide to not actually protect, since they can actually make even more money if it doesn’t work.

The other that comes up is fairly frequently is them contacting people claiming that a website has been hacked and that they can clean it, without SiteLock actually checking to see if the website is actually hacked. One example of that we were contacted about involved a website that had been actually hacked, for which the person who took over resolving that decided to start fresh, only reusing the domain name. So the website would have been clean at the point that SiteLock contacted them, which didn’t stop SiteLock from charging them for a cleanup:

When the site was hacked, the domain was blacklisted by every major blacklister, however,since I built the new site from scratch, it was clean when it went live. In spite of that, Sitelock contacted me the day after bringing the new site live that they were in the process of cleaning malware from the site and to contact them as it was going to involve manual removal and additional costs above what the plan that came with WordPress covers. They offered me two options, 300 to clean the site and submit to the blacklisters for review or 299 (in three installments) to clean the site and provide manual removal coverage for three months, after which I could continue with the scan and removal tool and add manual removal coverage for 49.00 per month from then on.

Beyond the fact that SiteLock was charging them for an unneeded cleanup, a website shouldn’t need continuing removals of malicious code. If that is the case, that would usually indicate that the original hack cleanup wasn’t done properly and the hacker could get back in, in that case the person who did the original hack cleanup should go back in and get the issue fixed for free (we certainly would want to do that for a client).

What SiteLock then did for that monthly fee doesn’t sound great either:

I have not been able to make it even a week (in two months) without Sitelock sending me some scary critical security warning email concerning the site. One of them said that they were cleaning malware, which I had a hard time believing since I had really good passwords, 2 step verification and login limiting onthe site. It turned out, the “malware” was a file that was created when I installed the Ithemes security plugin.All the other warnings were the result of them constantly not being able to connect and access the files in ordder to scan, which I don’t understand since I had not changed the passwords and each time, the problem ended up being resolved without a clear explanation as to how or why it happened in the first place.

Based on what we are seeing we have some recommendations if you are contacted by SiteLock or if your web hosts is recommending using them:

Get a Second Opinion

Based on what we are seeing it sounds like SiteLock sometimes is claiming that websites have been hacked that haven’t actually been hacked, so it would be a good idea to get a second opinion as to whether you have been hacked when you are contacted by them.

This is a good idea in other instances as well, since we sometimes see web hosts claiming a website has been hacked due to issues that were caused by something that was actually unrelated to a hack or them not double checking results of antivirus scanners (which can produce some bad false positives).

We are happy to do a free check to see if a website is actually hacked (we always will do that before taking on the clean up of a hacked website), so we are happy to provide you with a second opinion.

Hire Someone Who Properly Cleans Up Hacked Websites

If your website has in fact been hacked it is important to make sure you are hire someone that does a proper hack cleanup. You don’t want to be like many of our clients who hire to us to re-clean their hacked website after the first company they hired didn’t do those things.

The three main components of a proper hack cleanup are:

Cleaning up the malicious code and other material added by the hacker.
Securing the website (that often means getting the software on the website up to date).
Attempting to determine how the website was hacked.

While determining how the website was hacked is often not possible to do due largely to web hosts failure to store log files on a long term basis (something that we found SiteLock had not rectified with at least one of their hosting partners), we have found going through the process is important to get a hacked website fully cleaned. If the source of hack hasn’t been determined then that increases the chances that the security issue hasn’t been resolved and that the website will get hacked again.

We would recommend asking the companies what there hack cleanup service involves and if they don’t mention that they do those things, then you probably should look elsewhere.

Securing Your Website

One really important thing to understand it isn’t naturally for websites to get hacked. For that to happen something must have gone wrong. So the solution to keeping your website secure is to make sure you are taking the proper security measures with your website, instead of going with a security product or service that doesn’t do those things and instead make bold claims that it will keep you secure some other way.

It also important to understand that the chances of a website being hacked are pretty small, so when you see people saying that they use a service and haven’t been hacked, it is entirely possible that the service had nothing to do with them not being hacked.

WordPress Leaks Potentially Sensitive Information From Private Posts and Pages

Over at our Plugin Vulnerabilities service we are in the process of trying to help to get a fairly serious security issue with a WordPress plugin fixed. In the process of doing that we have noticed an issue with WordPress that impacts more than this plugin. Without getting into the details of it, since a fix is still in progress, the plugin created WordPress pages which provide access to non-public data. These were accessible by the public, which was a problem. As part of trying to fix this, these pages were intended to be made private (we say intended because that wasn’t done right). This would have worked in private pages were totally private, but it turns on they are not.

Here is how the WordPress documentation describes what the impact of setting a post’s or page’s visibility to private:

Private content is published only for your eyes, or the eyes of only those with authorization permission levels to see private content. Normal users and visitors will not be aware of private content. It will not appear in the article lists. If a visitor were to guess the URL for your private post, they would still not be able to see your content. You will only see the private content when you are logged into your WordPress blog.

Despite the claim that “normal users and visitors will not be aware of private content”, that isn’t totally true. If you have your permalink structure set to include the title of the page in it, which is fairly common set up, then someone can find out the titles of private posts and pages.

You do that by taking advantage of WordPress’ automatic redirection from plain URLs to the chosen permalink structure. Lets say a post with ID number 12 was titled Surprise Party For Julie In Accounting, when accessing

WordPress Releases Version 2.6

WordPress to automatically redirects you to

http://example.com/surprise-party-for-julie-in-accounting/

The page you see though gives no indication that a private page exists, as the documentation suggest:

Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search? Search for:

By enumerating through potential ID numbers you can see what the titles of all private posts and pages on a website are.

Coming back to the plugin, the title of those pages contains enough information to allow some access the non-public data. While the plugin shouldn’t have you used pages in the way it did, we suspect that in other cases private posts or pages could also contain sensitive information in the title that isn’t meant to be public, as it is now.

After noticing this we thought that we should bring this to the attention of the WordPress developers since it doesn’t seem like this should be this way. It turns out that someone already did that 8 years ago, back around the time of WordPress 2.3.1. But 7 years ago that ticket was closed and marked as “wontfix”. Maybe there was some good reason for that, but the only comment included with that change was “there’s a dup of this one somewhere, and it shoud get wontfixed too.” The fact that a potential security issue was treated in this way is more than a little concerning.

Does the Vulnerability Fixed in WordPress 4.2.1 Also Impact WordPress 3.7, 3.8, and 3.9?

Update (May 7, 2015): WordPress has now released versions 3.7.8, 3.8.8, and 3.9.6 that fix the vulnerability described below.

Last week a vulnerability in WordPress was disclosed and fixed in version 4.2.1. While WordPress only officials supports one version at a time, since the introduction of automatic updates in WordPress 3.7 they have been releasing security updates for all older releases that include the automatic updates feature. This time though only updates for 4.0 and 4.1 were released.

An update for 3.9 has a Codex entry, which indicates that the version, 3.9.6, was released to deal with this. But that version doesn’t appear to exist. Updates for 3.7 and 3.8 also had Codex entries, but those entries were deleted last Friday.

We were curious as to what was going on (as are others) since knowing the full implications of vulnerabilities that impact WordPress is important when we are cleaning up hacked WordPress websites. So we decided to do some testing to see if the vulnerabilities actually impacted versions 3.7-3.9 and they haven’t been fixed or if those versions are not vulnerable.

When using the sample exploit code provided for the vulnerability we found that vulnerability is not exploitable in versions 3.7-3.9 in the form given. The reason for this is that in WordPress 4.0-4.2 a character near the beginning of the malicious comment is encoded:

<a title=&#8217;x onmouseover=alert(unescape(/hello%20world/.source))

That allows the malicious code that begins “onmouseover” to be executed. In 3.7-3.9 that encoding doesn’t occur:

<a title='x onmouseover=alert(unescape(/hello%20world/.source))

So the “onmouseover” is treated as part of the title attribute instead of as code that should be executed, so no malicious code is run.

The underlying problem that leads to all of this, that WordPress didn’t properly check to make sure that comments longer then could be stored are properly handled also does exist in these versions, so it is possible somebody could figure out another way to exploit this in versions 3.7-3.9. If you are still running 3.7-3.9 we would recommend you upgrade to at least 4.0.4 as soon as possible. Though, it would be best that anyone still running a version below 4.2.1 to upgrade to that version.