[SHOCKING] Cross-site scripting vulnerability in millions of web sites




In August 2014 I found a severe cross-site scripting security vulnerability in the latest version (1.13.0) of the ‘jQuery Validation Plugin‘ during a security penetration test for a customer. This jQuery plugin which adds easy form validation functionality to a web site, is written by a core developer of the highly popular jQuery JavaScript framework.

As of speaking this vulnerability still exists and hasn’t been patched. It seems that on first sight 6.000+ web sites are vulnerable. jQuery hasn’t responded to my report of this vulnerability. That’s why I chose for full public disclosure, so other jQuery users can inform themselves about the safety of this validation plugin.


August 20, 2014
I reported this vulnerability to the developer of this plugin via his personal e-mail address. Did not get a response from him.

September 8, 2014
Sent him a reminder. Still got no response.

November 7, 2014
As a last resort I disclosed this vulnerability to the generic jQuery functional e-mail account ([email protected]).

November 13, 2014
Notified the generic jQuery e-mail account and the plugin developer about my intention to publicly release this vulnerability in the upcoming days. Again I didn’t get any response on this e-mail.

November 14, 2014
Just checked and the vulnerability is still not fixed in their latest version (1.13.1).

November 18, 2014
Full public disclosure on this web log.

Searching in their bug tracker
I was curious if this cross-site scripting vulnerability was added to their bug tracker after my disclosure. Couldn’t find it. Then I searched further if this plugin had other security vulnerabilities in the past. Someone posted on their bug tracker:

Apparently I’m not the only one who didn’t get any feedback from this developer.

After 7 months (!) the developer responded to this bug report and closes it a few days later:


I was shocked. This vulnerability is known since June 2011. That’s already 3.5 years. The developer thinks it’s “not a big deal”.

When I perform a security assessment as part of a quality assurance process, most of the time this kind of vulnerability poses a high security risk to a company. Such security finding is blocking a new software release from going to production from a security policy point of view. So, that’s certainly a big deal.

Searching Google to find vulnerable web sites
When writing this article, I wanted to know how wide spread this vulnerability was. So I quickly crafted a few Google Dorks to find vulnerable web sites.

By looking into the vulnerable source code of the jQuery Validation Plugin, I found a text string that would indicate candidate sites that might be vulnerable. Google returned 12.100 search results when searching for this string:

6 v2

Google returned 257 entries when searching for the default location of the vulnerable file:

4 v2

It’s frightening to know that it’s only a tip of the iceberg of what Google can find. There will be a lot more vulnerable web sites than the 12.100 + 257 web sites that I quickly found via a simple search query.

12.000+ pages seem to be vulnerable
When browsing through a few search results, I quickly found multiple vulnerable web sites. First impression is that more than 12.000 pages are vulnerable to cross-site scripting. That translates to about 6.000 web sites. That’s serious!

Open Source Vulnerability Database: vulnerability #99044
Saw something interesting when browsing the search results of the second Google Dork above. Someone else also found this vulnerability and disclosed it on October 26, 2013 on the Open Source Vulnerability Database (OSVDB) web site:

Clearly I’m not the first security researcher that found this problem, and certainly not the only one who worries about it.

Sadly, the plugin developer seems to be careless about security and leaves his software and users vulnerable. Even after multiple security researchers expressed their concerns to him.

Technical vulnerability details: full disclosure

The vulnerability exists in a CAPTCHA demonstration script.

On line 69 in /demo/captcha/index.php the PHP variable $_SERVER[‘PHP_SELF’] is printed without any user input sanitation:

[..] <a href=”<?php echo $_SERVER[‘PHP_SELF’]; ?>” id=”refreshimg” title=”Click to refresh image”> [..]

This make JavaScript injection possible by requesting the following URL:


The following HTML will be printed by the web server:

[..] <a href=”/demo/captcha/index.php/”><script>alert(1)</script><br alt=”” id=”refreshimg” title=”Click to refresh image”> [..]

The injected JavaScript code ‘<script>alert(1)</script>’ will be rendered by a web browser: