For years, jQuery has been the go-to JavaScript library for simplifying DOM manipulation, AJAX calls, and event handling. It provided developers with a way to write less code and support more browsers back when cross-browser inconsistencies were a daily headache. Even today many legacy web applications still rely on jQuery 3.2.1 or older versions because they "just simply work." But as we've seen over time, convenience often comes at the cost of hidden complexity and sometimes a vulnerability.

Two of the most impactful client-side security flaws in jQuery's history appeared in versions before 3.4.0 and 3.5.0. which are Prototype Pollution (CVE-2019–11358) and DOM-based Cross-Site Scripting (XSS). Both affect jQuery 3.2.1 and in this review, we will take a closer look at what's going on under the hood while trivially verifying those with a few lines JS.

Prototype Pollution in JQuery ( CVE-2019–11358)

JavaScript objects are built on prototypes which are shared blueprints from which all instances inherit. Modifying Object.prototype effectively changes the behavior of every object in the environment.

In jQuery versions before 3.4.0, the method $.extend(true, target, source) which performs deep merging of objects, did not correctly guard against the special property __proto__. This means that if an attacker passed untrusted data containing a __proto__ key, jQuery would happily merge it into the base Object.prototype, thereby "polluting" every object on the page.

This issue was discovered and disclosed in early 2019 and tracked as CVE-2019–11358. It affected not just standalone web apps but also popular platforms such as Drupal and Backdrop CMS and other plugins which embedded vulnerable jQuery versions.

To verify this issue, we use the following exploit.

let target = {};
let payload = JSON.parse('{"__proto__": {"polluted": "yes"}}');
$.extend(true, {}, payload);
console.log({}.polluted);

Once executed, jQuery writes that polluted property into the global object prototype. Now any newly created object — even {} — will automatically inherit the property of polluted as "yes".

This silent corruption can have far reaching consequences including logic checks may be bypassed, input validation can fail unexpectedly and application behavior can be manipulated in ways developers never intended.

DOM-based Cross-Site Scripting (XSS) in jQuery

DOM-based XSS occurs when user controlled input is inserted into a webpage's DOM without proper sanitization, leading to JavaScript execution. In this case of jQuery, the problem stemmed from how HTML fragments containing <option> elements were handled by methods such as .html(), .append(), .prepend(), etc.

In versions ≥1.0.3 and 3.5.0, jQuery didn't properly sanitize HTML containing <option> tags before inserting it into the DOM. Even sanitized strings could trigger JavaScript execution due to how browsers parsed and normalized nested HTML inside <option> elements.

In our verification attempt, we use the following script to trigger an XSS.

$("<option><img src=x onerror=alert('XSS')></option>").appendTo("select");

When executed in a page using jQuery 3.2.1, this snippet results in an alert box popping up meaning arbitrary JavaScript execution was possible simply by injecting HTML fragments.

This issue is very dangerous because DOM XSS in a widely used library like jQuery multiplies the attack surface. Even if developers sanitize input, passing it through vulnerable jQuery DOM manipulation methods can reintroduce risk. Attackers could chain this with other weaknesses to steal session data, modify UI behavior, or perform phishing-style interactions all without server-side involvement.

This issue was later patched in jQuery 3.5.0, under advisories related to improper neutralization of HTML input.

Recommendations

Both vulnerabilities in jQuery 3.2.1 of Prototype Pollution (CVE-2019–11358) and DOM XSS highlight the same root lesson: Client-side libraries are not "safe" by default and inherited code can be just as dangerous as unpatched server logic.

When developers use old versions for compatibility or convenience, they unknowingly invite risk through dependencies that silently expose entire applications.

So the recommendations include;

I) Update vulnerable jQuery versiona immediately to version 3.5.0 or higher as the maintainers patched both vulnerabilities in successive releases.

II )Many CMSs and plugins still bundle jQuery 3.2.x internally, so it is required to check /vendor/ or /static/js/ directories ensure they are not inherited from vulnerable jQuery versions.

As final thoughts, this is a reminder that even battle tested libraries like jQuery, once essential for web development can carry legacy flaws that persist for years simply because "it's always been there."