We generally avoid following news coverage of web security since it is of such poor quality and when we do have to look at examples of it due to a news alert we have to keep track of vulnerabilities in WordPress that view is reinforced. Take this post on ZDNet’s Zero Day blog, “Zero-day in popular jQuery plugin actively exploited for at least three years“, by Catalin Cimpanu, which makes this claim:

It is pretty clear from the videos that the vulnerability was widely known to hackers, even if it remained a mystery for the infosec community.

That would news to us since we were aware that there are security issues related to how others implement usage of the software jQuery File Upload for years. One such example of was with the WordPress plugin Creative Contact Form, which was disclosed in October of 2014.

The post goes on to claim it was a secret:

The vulnerability was one of the worst kept secrets of the hacker scene and appears to have been actively exploited, even before 2016.

Again this isn’t a secret, it has been well known, it just wasn’t known to the source of the post, Larry Cashdollar. That is someone that we have seen disclosing real vulnerabilities, but also doesn’t always provide accurate information. Just last month after he incorrectly claimed that vulnerabilities in a WordPress plugin had been fixed, we brought that to his attention on Twitter, but we never got a response, which isn’t a great indication of his concern for accuracy and seems like a good reason he shouldn’t be a sole source for a journalist, as he was here.

The Zero Day blog isn’t the only source spreading this false information, Ionut Ilascu at the Bleeping Computer wrote “jQuery File Upload Plugin Vulnerable for 8 Years and Only Hackers Knew“, which makes this false claim:

Of the thousands of plugins for the jQuery framework, one of the most popular of them harbored for at least three years an oversight in code that eluded the security community, despite public availability of tutorials that explained how it could be exploited.

.htaccess Files Haven’t Been Disabled

Making it seem worse to rely solely on Larry Cashdollar, based on what wrote on the blog of his employer Akamai, you can see he doesn’t have a great understanding of how web servers are normally configured and therefore why what he is claiming is at issue with that library isn’t all that accurate, as he writes this:

After comparing our test configurations over email we soon realized that the Apache maintainers disabled support for .htaccess since Apache version 2.3.9.  It appears they’ve done this to improve performance as the server doesn’t have to check for this file everytime it accesses a directory. Moreover, the change was made to prevent users from overriding security features that were configured on the server.

So Apache had good reasons to disable .htaccess, but their changes left some developers and their projects open to attack, especially if they relied on .htaccess as a security function.

.htaccess files having been disabling would be news to almost anyone running WordPress website, considering that many of them would no longer be function if that were true. It looks like Larry doesn’t have a good understanding of web hosting and just assumed that it being stated in the Apache documentation,  “This prevents the use of .htaccess files in all directories apart from those specifically enabled.” and “Note that this setting is the default since Apache 2.3.9.”, somehow meant that generally these files are disabled instead of stock configuration limiting where they can be used, which doesn’t apply to how things are normally configured in the real world. That would have been a good reason for journalists to have a second source for their stories on this, something that is true with so many stories where they simply repeat inaccurate claims by security companies or researchers and the end up acting more as stenographer than a journalist.

Instead they repeat this incorrect information, as Michael Heller at TechTarget did:

After Cashdollar reported the jQuery plugin vulnerability to its creator, Sebastian Tschan, the German developer who goes by the nym “Blueimp,” the two worked together and discovered the issue was caused by a change in the Apache HTTPD server. The change was made in Apache version 2.3.9 — made five days before release of the first version of jQuery File Upload in 2010 — and it disabled support for .htaccess web server configuration in order to prevent security features from being overridden. Unfortunately, Tschan’s plugin relied on .htaccess to implement security controls.

The Real Issue

The real issue here, which again has been known, has to do with what types of files can be uploaded, which is a common issue with file upload functionality. That would be something someone implementing the library would want to do, as the types of files they would want to be uploaded would vary. What has been changed though is to limit that to certain types of images by default.