CVE-2020-11022

What it actually does

This is a DOM-based cross-site scripting flaw in jQuery versions 1.12.0 through versions before 3.5.0. When an application passes attacker-influenced HTML into jQuery DOM manipulation methods such as .html(), .append(), .prepend(), .before(), .after(), or .replaceWith(), jQuery’s HTML handling can transform otherwise sanitized markup in a way that causes executable content to be inserted into the page. Successful exploitation runs attacker-controlled JavaScript in the security context of the affected web application. The flaw requires a vulnerable application code path and user interaction, but public exploit techniques are available and the EPSS score is very high, indicating broad real-world exploit likelihood.

Why it matters to the business

An affected web application can be used to run malicious code in users’ browsers, allowing attackers to steal session data available to JavaScript, read or modify page content, perform actions as the user, redirect users to phishing pages, or compromise administrative workflows. Because jQuery is widely embedded directly, bundled in frontend builds, and served from CDNs, exposure may persist in older pages even after backend systems are patched. Although this issue is not listed in CISA KEV and is not specifically associated with ransomware, the very high EPSS score and availability of exploit code make it a priority for internet-facing and authenticated business applications.

How an attack unfolds

An attacker first identifies a page that accepts or displays attacker-controlled HTML, such as content from a URL parameter, comment field, profile field, rich-text editor, message body, search result, API response, or third-party feed. The application may sanitize that input, but then passes the resulting HTML string to a vulnerable jQuery DOM manipulation method. In vulnerable jQuery versions, the HTML pre-processing and browser parsing behavior can alter the sanitized markup so that executable JavaScript is created in the DOM. The attacker delivers the malicious input through a link, stored content, embedded widget, or manipulated data source. When a victim visits the affected page, the attacker’s script executes in the application’s origin and can access same-origin data available to JavaScript, abuse application functionality with the victim’s permissions, or modify the page to capture credentials or tokens. The provided threat-actor labels do not identify a specific named adversary; exploitation should be treated as opportunistic and broadly reproducible because public XSS payload patterns exist.

How to fix it

Upgrade all jQuery instances to version 3.5.0 or later; preferably use the latest supported 3.x release available for the application. Remove duplicate or legacy jQuery copies from static assets, vendor directories, frontend bundles, CMS themes, plugins, and CDN references. Confirm that minified, bundled, and cached assets are rebuilt and redeployed. If immediate upgrade is not possible, avoid passing untrusted HTML strings to jQuery DOM manipulation methods; use safe DOM APIs such as textContent or createElement for untrusted data, or use a robust sanitizer such as DOMPurify configured for the application context before insertion. Add or strengthen Content Security Policy to reduce XSS impact, including disallowing inline scripts where feasible, but do not treat CSP as a replacement for upgrading. Review any inventory entry that maps this jQuery vulnerability to unrelated packages, because the authoritative affected component is jQuery before 3.5.0.

How to confirm the fix worked

Confirm exposure by inventorying served JavaScript assets and verifying that no page loads jquery-1.12.x, jquery-2.x, jquery-3.0.x, jquery-3.1.x, jquery-3.2.x, jquery-3.3.x, or jquery-3.4.x. Check direct script tags, CDN URLs, bundled JavaScript, source maps, lockfiles, package manifests, CMS plugin assets, and third-party theme assets. In a browser console, validate the runtime version with jQuery.fn.jquery where jQuery is globally exposed. Confirm remediation by ensuring all deployed pages serve jQuery 3.5.0 or later and that caches/CDNs no longer return vulnerable files. Use SCA tooling, frontend dependency scanning, and dynamic web crawlers to detect residual vulnerable jQuery references. For code validation, search for uses of jQuery DOM insertion APIs receiving data derived from user input, URL fragments, query strings, API responses, postMessage events, or rich-text content, and verify those paths use safe encoding or sanitization appropriate to the sink.

Typical attack path

1. Identify a web application using jQuery 1.12.0 or later but earlier than 3.5.0.
2. Find an application code path where untrusted or semi-trusted HTML is inserted into the DOM using jQuery methods such as .html(), .append(), .prepend(), .before(), .after(), or .replaceWith().
3. Craft HTML that survives the application’s sanitizer but is transformed or reparsed into executable content by vulnerable jQuery behavior.
4. Deliver the payload through a stored field, reflected parameter, crafted link, compromised feed, or attacker-controlled content source.
5. Trick or wait for a victim to load the affected page.
6. Execute JavaScript in the victim’s browser under the vulnerable application’s origin.
7. Use the script to read accessible data, perform actions as the victim, alter page content, steal non-HttpOnly tokens, or redirect the user.

How to detect it

Retrospective detection should focus on evidence that malicious HTML payloads were submitted to or served by the application, followed by browser-side execution indicators. Review WAF, reverse proxy, CDN, web server, and application logs for requests containing suspicious HTML tags, event-handler attributes, JavaScript URLs, encoded script-like content, or payloads targeting select/style/option parsing behavior. Examine stored user-generated content, rich-text fields, CMS content, comments, messages, profile fields, and imported feed data for payload fragments that include event handlers such as onerror or onload, SVG-based script triggers, malformed nested tags, or encoded JavaScript. Review CSP violation reports for blocked inline script execution, unexpected external script destinations, or eval-like behavior on pages known to use vulnerable jQuery. Inspect browser error telemetry and frontend monitoring for spikes in script errors, unusual redirects, or unexpected DOM changes. Correlate suspicious payload submissions with affected page views by privileged users or high-value accounts. Because DOM XSS often executes only in the browser and may not create server-side artifacts, absence of server logs is not proof of non-exploitation. Indicators below are useful for hunting but are not definitive by themselves, as many are common XSS test strings.

• <option><style></option></select><img
• <select><style></select><img
• <img src=x onerror=
• <svg/onload=
• onerror=alert(
• onload=alert(
• javascript:alert(
• %3Cimg%20src%3Dx%20onerror%3D
• %3Csvg%2Fonload%3D
• %3Coption%3E%3Cstyle%3E%3C%2Foption%3E%3C%2Fselect%3E%3Cimg
• jquery-1.12
• jquery-2.
• jquery-3.0
• jquery-3.1
• jquery-3.2
• jquery-3.3
• jquery-3.4
• .html(
• .append(
• .prepend(
• .replaceWith(
• .before(
• .after(

What your security team should do

• Prioritize internet-facing applications, administrative portals, identity workflows, payment flows, and applications handling sensitive user data because browser-executed code can abuse user sessions.
• Upgrade every deployed copy of jQuery to 3.5.0 or later, preferably the latest supported 3.x release, including bundled, minified, vendored, CDN-hosted, plugin-provided, and legacy copies.
• Run SCA and web asset discovery to identify stale jQuery versions that may not appear in backend package inventories.
• Search application code for .html(), .append(), .prepend(), .before(), .after(), .replaceWith(), .wrap(), .wrapAll(), and similar jQuery sinks that may receive untrusted HTML.
• Where HTML rendering is required, standardize on a maintained sanitizer and validate sanitizer configuration with XSS regression tests.
• Deploy or tighten Content Security Policy to reduce exploit impact, while continuing to treat the jQuery upgrade as mandatory.
• Review web access logs, WAF logs, application logs, RUM/error telemetry, and CSP violation reports for XSS payload fragments and anomalous script execution attempts.
• Invalidate stale CDN and browser-cacheable assets after remediation to ensure users receive patched JavaScript.
• Add regression tests that render representative untrusted HTML payloads and assert that scripts and event handlers do not execute.
• Treat the high EPSS score and public exploit availability as an urgency signal even though the issue is not currently listed in CISA KEV.