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.