CVE-2020-11023 Explained: jQuery XSS, CISA KEV, and the Risk of Legacy DOM Manipulation

CVE-2020-11023 is a useful reminder that vulnerability severity and vulnerability priority are not the same thing.

When the jQuery vulnerability was disclosed in April 2020, it looked like another moderate-severity client-side security bug affecting old versions of an extremely common JavaScript library. The vulnerability received a medium CVSS rating, a patched jQuery release already existed, and many organizations consequently treated the issue as something that could be addressed during routine frontend modernization.

That interpretation became much harder to defend on January 23, 2025.

On that date, the U.S. Cybersecurity and Infrastructure Security Agency added CVE-2020-11023 to the Known Exploited Vulnerabilities Catalog, explicitly stating that the addition was based on evidence of active exploitation. CISA required U.S. Federal Civilian Executive Branch agencies to remediate the vulnerability by February 13, 2025 and recommended that other organizations also prioritize KEV vulnerabilities. (GovDelivery)

That change matters.

CVE-2020-11023 is not suddenly a different vulnerability. Its technical characteristics did not become more severe in 2025. What changed was the evidence available to defenders: a vulnerability that had previously been evaluated largely through theoretical exploitability and CVSS scoring now had confirmed exploitation evidence.

For vulnerability management teams, that distinction should immediately change prioritization.

CVE-2020-11023 at a Glance

Attribute	Details
CVE	CVE-2020-11023
Component	jQuery
Vulnerability type	Cross-Site Scripting
CWE	CWE-79
Affected versions	jQuery >= 1.0.3 and < 3.5.0
Patched version	jQuery 3.5.0
NVD CVSS 3.1	6.1 Medium
GitHub CNA score	6.9 Medium
CISA KEV	Yes
KEV date added	January 23, 2025
CISA remediation deadline	February 13, 2025
Required CISA action	Apply vendor mitigations or discontinue use if mitigations are unavailable

NVD describes the vulnerability as affecting jQuery versions from 1.0.3 up to, but not including, 3.5.0. Under vulnerable conditions, HTML containing <option> elements from an untrusted source can result in arbitrary JavaScript execution when passed into jQuery DOM manipulation functions such as .html() or .append(). Importantly, the problem could occur even when the HTML had already gone through sanitization. (NVD)

That last characteristic is what makes CVE-2020-11023 particularly interesting.

This is not simply another case where a developer directly writes raw attacker input into innerHTML.

Instead, a developer could believe the dangerous content had already been sanitized.

The application might therefore look secure at the source level:

const sanitizedHTML = sanitize(userControlledHTML);

$("#result").html(sanitizedHTML);

The developer’s security assumption is straightforward:

Attacker input
      ↓
HTML sanitizer
      ↓
Safe HTML
      ↓
jQuery
      ↓
Browser DOM

CVE-2020-11023 demonstrated that this mental model could break.

The real pipeline could behave more like:

Attacker-controlled HTML
          ↓
      Sanitizer
          ↓
Apparently safe HTML
          ↓
jQuery DOM manipulation logic
          ↓
HTML structure transformed/reparsed
          ↓
Browser HTML parser
          ↓
Executable DOM
          ↓
         XSS

The security boundary therefore did not end at the sanitizer.

Why CISA KEV Changes the Risk Calculation

CVE-2020-11023 was published on April 29, 2020. Nearly five years later, CISA added it to KEV.

CISA’s January 23, 2025 bulletin stated that the vulnerability had been added based on evidence of active exploitation. The agency did not provide a detailed public exploitation chain, victim list, or named campaign in that announcement, so defenders should avoid inventing attribution that CISA itself did not publish. What CISA did establish is the fact that exploitation had crossed the threshold required for KEV inclusion. (GovDelivery)

This distinction is critical because CVSS and KEV answer different questions.

CVSS asks something close to:

How severe could exploitation be under defined technical conditions?

KEV answers something much closer to:

Do we have sufficient evidence that attackers are actually exploiting this vulnerability?

CVE-2020-11023 illustrates why organizations that prioritize only by CVSS score can make poor decisions.

NVD currently scores it at 6.1, while GitHub’s CNA data reports 6.9. Both are still categorized as Medium. (NVD)

A purely score-driven vulnerability program might place dozens of CVSS 9.x vulnerabilities ahead of it indefinitely.

But once a vulnerability appears in KEV, the risk equation becomes:

Risk ≠ CVSS alone

Risk =
    exploitability
  × asset exposure
  × reachable vulnerable code
  × business impact
  × observed attacker activity

Confirmed exploitation dramatically changes one of those variables.

That is exactly why a Medium-severity XSS vulnerability can deserve remediation ahead of theoretically more severe vulnerabilities for which no exploit path exists in the organization’s environment.

What Exactly Is Vulnerable?

According to the official jQuery advisory, vulnerable releases are:

jQuery >= 1.0.3
and
jQuery < 3.5.0

The patched version is:

jQuery 3.5.0

The issue was not limited to npm installations. GitHub’s advisory tracks affected jQuery distributions across npm, Composer, NuGet, WebJars and related package ecosystems. (GitHub)

That breadth matters because jQuery is frequently not installed as an obvious top-level dependency.

It may appear inside:

CMS themes
WordPress plugins
administrative dashboards
legacy Java applications
WebJars
vendor bundles
embedded appliances
monitoring interfaces
network-management consoles
old internal portals
third-party widgets
archived frontend assets
ERP interfaces
support portals
reporting dashboards

In other words, searching package.json is useful, but it is not sufficient.

A vulnerable jquery.min.js file might simply have been copied into:

/static/js/
/assets/
/vendor/
/public/
/wwwroot/
/resources/
/webapp/

years ago and never touched again.

This is one reason old JavaScript vulnerabilities can remain operationally relevant for much longer than security teams expect.

Understanding the jQuery XSS Attack Surface

To understand CVE-2020-11023, it is useful to distinguish three different concepts.

The first is attacker-controlled data.

The second is HTML sanitization.

The third is the DOM sink that eventually interprets the string as markup.

A safe application might use attacker input only as text:

$("#username").text(userInput);

In that case, markup is not supposed to be interpreted.

A riskier application might instead intentionally treat the content as HTML:

$("#content").html(userInput);

Most developers already recognize the second example as dangerous.

The more interesting case is:

const sanitized = DOMPurify.sanitize(userInput);

$("#content").html(sanitized);

Conceptually, that looks much better.

But CVE-2020-11023 existed precisely in a category where jQuery’s own HTML-processing behavior could interact with sanitized markup in an unexpected way.

The official jQuery security advisory specifically warns that passing untrusted HTML containing <option> elements to methods such as .html() and .append() could execute untrusted code even after sanitization. (GitHub)

The Role of the <option> Element

The vulnerability has an unusual historical root: browser compatibility.

Older versions of Internet Explorer had problematic behavior when <option> elements were inserted outside a <select> element.

To accommodate those browsers, jQuery used internal parsing logic that could temporarily wrap certain markup before letting the browser parse it.

Conceptually, input beginning with something like:

<option>Example</option>

could be transformed internally into a structure involving:

<select>
    <option>Example</option>
</select>

The jQuery team later explained that the option-related vulnerability resulted from this compatibility behavior. In the jQuery 3.5.1 retrospective, the developers noted that <option> elements were wrapped with <select> elements to compensate for IE9 parsing behavior. The security fix limited that compatibility path to the browser where it was actually required. (jQuery Blog)

This is an important software-security lesson.

Compatibility code is security-relevant code.

A transformation originally introduced to make markup work correctly in an obsolete browser eventually affected how attacker-controlled HTML was interpreted by modern browsers.

The resulting vulnerability emerged not because jQuery intentionally allowed JavaScript, but because:

sanitizer interpretation
        ≠
jQuery transformed representation
        ≠
browser's final DOM interpretation

An attacker’s objective is to exploit that disagreement.

Mutation After Sanitization Is the Core Security Problem

A modern sanitizer tries to reason about what a browser will eventually create from a particular HTML string.

Suppose a sanitizer examines a string and determines that dangerous markup is contained inside a context where it should remain inert.

If another library modifies that string after sanitization, the original security guarantee may no longer apply.

This pattern can be generalized as:

sanitize(x) → safe

transform(safe) → not necessarily safe

This class of vulnerability is especially dangerous because it violates a very common developer assumption:

Sanitization happened, therefore downstream HTML manipulation is safe.

That assumption is only correct if downstream components preserve the security-relevant semantics of the sanitized representation.

CVE-2020-11023 demonstrates why that is not always true.

A Simplified Safe-Lab Example

A harmless test environment can illustrate the relevant pattern.

Imagine an application receives HTML from a user, sanitizes it and then performs:

const input = getUserGeneratedHTML();
const sanitized = sanitizer(input);

$("#preview").html(sanitized);

With a vulnerable jQuery release, a specially structured combination of elements including <option> could cause jQuery’s internal parsing path to produce DOM semantics different from the sanitized representation.

For defensive testing, a benign execution marker is enough:

alert(document.domain);

There is no need to test session theft, credential harvesting or outbound data exfiltration.

The validation question is simply:

Can sanitized attacker-controlled markup become executable
after entering a jQuery DOM manipulation API?

If yes, the security boundary has failed.

.html() Is Not the Only API That Matters

One of the easiest mistakes during remediation is searching only for:

.html(

The vulnerability can involve multiple jQuery APIs that eventually feed HTML strings into jQuery’s manipulation pipeline.

Relevant review targets include code patterns such as:

$(htmlString)

element.html(htmlString)

element.append(htmlString)

element.prepend(htmlString)

element.before(htmlString)

element.after(htmlString)

The original researcher noted that the affected behavior extended beyond .html() because multiple APIs shared internal manipulation logic. (MKSB)

That means a security audit should search for HTML-producing sinks, not simply one vulnerable method name.

CVE-2020-11023 vs CVE-2020-11022

The two vulnerabilities are frequently discussed together because both were addressed during the jQuery 3.5 security work.

They should not, however, be treated as interchangeable identifiers.

CVE-2020-11023 is specifically described by the official advisory as involving untrusted HTML containing <option> elements passed to jQuery manipulation APIs. (GitHub)

CVE-2020-11022 covers another XSS problem involving jQuery’s HTML preprocessing behavior. Its advisory describes untrusted HTML being transformed through jQuery.htmlPrefilter() before reaching DOM manipulation methods. (GitHub)

The distinction matters during technical reporting.

It is common to see scanners, blogs and vulnerability descriptions merge the two bugs into a generic statement such as:

old jQuery htmlPrefilter XSS

That is an oversimplification.

Both vulnerabilities demonstrate dangerous post-sanitization HTML transformation, but they involve different internal behaviors.

For CVE-2020-11023, the <option> handling and compatibility wrapping path are especially important.

Why a 2020 jQuery Vulnerability Still Exists in 2026

One might reasonably ask why a vulnerability patched more than six years ago should still matter.

The answer is that frontend dependencies do not disappear simply because a patch exists.

jQuery has historically been embedded into enormous numbers of applications.

A typical legacy application stack might look like:

Enterprise application
        ↓
Server-side framework
        ↓
Admin interface
        ↓
UI theme
        ↓
Vendor JavaScript bundle
        ↓
jQuery 2.x

The application team may not even consider jQuery part of its direct dependency inventory.

The file may have been introduced by a theme vendor ten years earlier.

That creates an important difference between:

dependency age

and:

dependency exposure

Old does not mean unreachable.

An old admin console can still be exposed on the public Internet.

An old VPN appliance can still contain a browser-based management interface.

An old internal helpdesk application can still process attacker-controlled ticket content.

An old CMS plugin can still render user-generated markup.

CISA’s KEV decision is therefore useful precisely because it forces organizations to reevaluate assets that may have escaped normal dependency-maintenance processes.

Where Exploitation Becomes Realistic

Finding jQuery 3.4.1 does not automatically prove exploitable CVE-2020-11023.

A useful risk analysis should answer four questions.

Can an attacker influence HTML?

Look for data originating from:

URL parameters
API responses
profile fields
comments
forum posts
support tickets
CMS content
product descriptions
email bodies
chat messages
uploaded metadata
search results
third-party integrations
Markdown conversion
rich-text editors

Does the application intentionally render that data as HTML?

For example:

$("#message").html(data.message);

is more interesting than:

$("#message").text(data.message);

Is the content processed by vulnerable jQuery?

Check whether the relevant page actually executes a version below 3.5.0.

Can the attacker-controlled content reach the vulnerable DOM path?

This is the most important question.

The practical exploit graph is:

Attacker-controlled source
          ↓
Potential sanitizer
          ↓
HTML string
          ↓
jQuery DOM sink
          ↓
Vulnerable parsing behavior
          ↓
Browser-generated DOM
          ↓
JavaScript execution

Breaking any of these edges may eliminate practical exploitability.

This is why version-only scanners provide useful inventory data but do not provide complete exploitability analysis.

Stored XSS Can Be More Dangerous Than Reflected XSS

CVE-2020-11023 can become significantly more serious when the vulnerable data flow occurs in a stored-content workflow.

Consider a hypothetical enterprise helpdesk:

External user
      ↓
Submits support ticket
      ↓
Ticket description stored in database
      ↓
Administrator opens ticket
      ↓
Frontend renders description
      ↓
Old jQuery DOM manipulation
      ↓
XSS executes in administrator session

That is a much more consequential scenario than:

Attacker sends malicious link
      ↓
Victim voluntarily clicks link
      ↓
Reflected XSS

The underlying CVE is the same.

The business impact is not.

Stored execution in administrative workflows can expose privileged application functionality, sensitive data and management APIs available to the victim’s browser.

The lesson for defenders is therefore:

Do not assign application risk based solely on the CVE’s global CVSS score.

Evaluate the privilege level of the browser context in which JavaScript could execute.

Administrative Interfaces Deserve Special Attention

Legacy jQuery is especially common inside administrative interfaces.

Those interfaces often combine several dangerous characteristics:

old frontend dependencies
+
high-privilege users
+
rich user-controlled data
+
HTML-heavy interfaces
+
weak CSP

For example, an admin dashboard might display:

customer names
device labels
ticket descriptions
HTML email
monitoring messages
log fields
uploaded metadata
CMS drafts

If any of those inputs are attacker-controlled and inserted through vulnerable DOM manipulation code, an otherwise modest XSS vulnerability can become a high-impact attack path.

Discovering Vulnerable jQuery Versions

Start with dependency management systems where possible.

For npm:

npm ls jquery

To inspect a lock file:

grep -n '"jquery"' package-lock.json

For Yarn:

yarn why jquery

For pnpm:

pnpm why jquery

But do not stop there.

Legacy applications may contain manually copied libraries.

A filesystem search can help identify candidates:

find . -iname 'jquery*.js'

You can also search JavaScript source for version banners:

grep -Rni "jQuery v" .

Another useful indicator is:

grep -Rni "jquery-3.4" .

or equivalent historical version strings.

These approaches are imperfect because minification and bundling can remove obvious filenames, but they provide a useful initial inventory.

Checking the Version at Runtime

When jQuery is exposed globally, browser developer tools can often reveal the active version:

jQuery.fn.jquery

or:

$.fn.jquery

A vulnerable result could look like:

1.12.4
2.2.4
3.4.1

A patched result would be:

3.5.0

or newer.

As of September 2026, the current stable jQuery major release is jQuery 4.0.0, released in January 2026. The official CDN still lists jQuery 3.7.1 as the latest stable 3.x release for applications that need to remain on the 3.x branch. (jQuery Blog)

Therefore, defenders should distinguish between:

minimum security fix:
3.5.0+

and:

modernization target:
latest compatible supported release

Simply upgrading to exactly 3.5.0 may close CVE-2020-11023, but organizations maintaining the application long term should generally evaluate migration to a newer maintained branch.

Look Beyond the Primary Application Bundle

A common false negative occurs when security teams inspect:

app.js
vendor.js
main.js

but ignore unrelated application paths.

The vulnerable file may exist only on:

/admin/
/legacy/
/reports/
/install/
/setup/
/portal/
/support/
/old-dashboard/
/plugins/
/themes/

It may also be dynamically loaded from a CDN.

For example:

<script src="/legacy/jquery-2.2.4.min.js"></script>

or:

<script src="https://cdn.example.com/jquery/3.4.1/jquery.min.js"></script>

Asset discovery therefore needs to include the deployed application rather than only the development repository.

Search for Dangerous HTML Sinks

Once an affected jQuery version is identified, the next step is reachability analysis.

Useful searches include:

grep -Rni "\.html(" .

grep -Rni "\.append(" .

grep -Rni "\.prepend(" .

However, security reviewers should examine the data flowing into those calls.

This is relatively safe:

$("#status").html("<strong>Online</strong>");

The HTML is developer-controlled.

This deserves investigation:

$("#result").html(response.description);

because response.description may originate externally.

This is also worth reviewing:

const content = sanitize(response.description);

$("#result").html(content);

because CVE-2020-11023 specifically challenges the assumption that generic sanitization necessarily protects older jQuery DOM manipulation paths.

Dynamic Testing

A defensive test should validate whether attacker-controlled data actually reaches an HTML sink.

Browser instrumentation can be useful.

For example, during development testing, teams can temporarily wrap sensitive methods and log their inputs:

const originalHtml = $.fn.html;

$.fn.html = function(value) {
    if (typeof value === "string") {
        console.log("jQuery .html() called with:", value);
    }

    return originalHtml.apply(this, arguments);
};

Similar instrumentation can be applied to .append().

This does not itself detect CVE-2020-11023.

It helps answer a more useful question:

Where does the application dynamically convert strings into HTML?

Those call sites can then be traced back to their data sources.

Do Not Treat a Scanner Finding as Proof of Exploitation

A vulnerability scanner might report:

jquery-3.4.1.min.js detected
CVE-2020-11023

That is useful.

It proves that a vulnerable component exists.

It does not necessarily prove:

attacker-controlled HTML
    ↓
reachable vulnerable sink
    ↓
successful XSS

A mature vulnerability report should therefore distinguish:

Finding	What it proves
Vulnerable jQuery version	Component exposure
Dangerous .html() call	Potential sink
Attacker input reaches sink	Reachability
Sanitized payload mutates into executable markup	Vulnerability
JavaScript executes	Exploit confirmation

This evidence-driven approach reduces both false positives and false confidence.

The Correct Remediation: Upgrade jQuery

The primary fix is straightforward.

Upgrade to:

jQuery >= 3.5.0

The official GitHub advisory explicitly identifies 3.5.0 as the patched version. (GitHub)

Organizations still using 1.x, 2.x or early 3.x should strongly consider moving substantially beyond the minimum patch release instead of making the smallest possible version change.

For applications that can support the modern branch, jQuery 4.0.0 is now available. Organizations requiring the 3.x compatibility line can evaluate jQuery 3.7.1. (jQuery Blog)

Why the Upgrade Can Require Regression Testing

jQuery 3.5.0 contained deliberate security-related behavior changes.

The jQuery team warned that some existing applications could require code changes because internal HTML normalization behavior was modified. The release eliminated problematic transformations in jQuery.htmlPrefilter, and the option-related compatibility behavior was also constrained to environments where it was required. (jQuery Blog)

Therefore, teams upgrading a very old application should regression-test:

HTML insertion
template rendering
dropdown creation
form controls
plugins
rich-text components
legacy widgets
DOM construction
custom jQuery extensions

Breaking a few obsolete frontend assumptions is preferable to retaining exploitable DOM behavior, but production upgrades should still be tested carefully.

Be Careful With jQuery Migrate Compatibility Modes

jQuery Migrate is useful for identifying application code that depends on removed or changed APIs.

But compatibility restoration can sometimes reintroduce old behavior.

The jQuery 3.5 upgrade guide explicitly warns that restoring legacy HTML prefilter behavior means losing the relevant security protection and therefore requires additional care around HTML sanitization. (jQuery)

This produces an important rule:

Upgrade jQuery
+
restore insecure legacy behavior
=
potentially defeat part of the upgrade

Compatibility tools should therefore be treated as migration aids rather than permanent security bypasses.

Sanitization Still Matters

Upgrading jQuery does not mean developers should begin trusting arbitrary HTML.

If an application intentionally accepts user-generated markup, use a well-maintained HTML sanitizer such as DOMPurify and maintain it independently from jQuery.

The safer design remains:

const safeHTML = DOMPurify.sanitize(untrustedHTML);

container.innerHTML = safeHTML;

or the appropriate modern framework mechanism.

Whenever possible, avoid HTML entirely.

Instead of:

$("#username").html(username);

use:

$("#username").text(username);

The second API treats the value as text rather than markup.

That removes an entire class of parser-driven vulnerabilities.

Content Security Policy Is Defense in Depth

A strong Content Security Policy can reduce the consequences of many XSS vulnerabilities.

For example, applications can avoid allowing:

'unsafe-inline'

and restrict script execution to explicitly permitted sources.

However, CSP should not be used as the primary fix for CVE-2020-11023.

CSP configurations differ dramatically between applications, and complex applications frequently contain allowances that reduce its effectiveness.

The correct model is:

Patch vulnerable jQuery
+
eliminate unsafe DOM sinks
+
sanitize required HTML
+
deploy CSP

rather than:

Keep vulnerable jQuery
+
hope CSP blocks exploitation

Trusted Types Can Further Reduce DOM XSS Risk

Modern browser security architecture also offers Trusted Types.

Trusted Types can make dangerous DOM sinks reject ordinary strings unless the value has been produced by an approved security policy.

This can help prevent patterns where arbitrary strings reach:

innerHTML

and similar HTML interpretation APIs.

Notably, jQuery 4.0 added Trusted Types support, including support for TrustedHTML when used with relevant Content Security Policy directives. (jQuery Blog)

That represents the longer-term direction organizations should consider.

Instead of relying exclusively on developers remembering which strings are safe, browsers can participate in enforcing the trust boundary.

Why WAF Rules Are Not Enough

A Web Application Firewall may detect obvious payloads such as:

<script>alert(1)</script>

But CVE-2020-11023 exists precisely because the dangerous DOM can be produced through parser transformations.

The HTTP request does not necessarily contain markup that looks obviously executable.

Security inspection may see one representation.

The sanitizer may see another.

jQuery may transform it.

The browser then creates the final DOM.

This is why client-side parsing vulnerabilities are difficult to eliminate using network signatures alone.

A WAF can provide supplemental detection.

It cannot repair the vulnerable jQuery code.

Supply-Chain Inventory Is Part of the Fix

Another major lesson from CVE-2020-11023 is that JavaScript assets belong in vulnerability management.

Some organizations maintain excellent inventory for:

operating systems
containers
server libraries
databases
cloud infrastructure

but have poor visibility into:

frontend libraries
copied vendor scripts
CMS themes
static assets
JavaScript distributed inside appliances

That creates exactly the type of long-lived exposure represented by old jQuery.

Security teams should inventory both:

declared dependencies

and:

deployed client-side assets

because these are not always identical.

A Practical Remediation Workflow

An effective response to CVE-2020-11023 can be summarized as:

1. Inventory
        ↓
Identify jQuery < 3.5.0

2. Determine exposure
        ↓
Which applications actually load it?

3. Identify HTML sinks
        ↓
.html()
.append()
other DOM construction paths

4. Trace attacker-controlled inputs
        ↓
Can external data reach those sinks?

5. Validate safely
        ↓
Confirm DOM behavior using benign execution markers

6. Patch
        ↓
Upgrade jQuery

7. Regression test
        ↓
Check application compatibility

8. Harden
        ↓
Sanitization
CSP
Trusted Types
text APIs

9. Verify
        ↓
Rescan deployed assets

This workflow provides something a CVE scanner alone cannot provide: evidence about the actual attack path.

Prioritization Guidance After CISA KEV

Organizations should no longer treat CVE-2020-11023 as an ordinary historical jQuery finding.

CISA’s KEV designation means active exploitation evidence exists. (GovDelivery)

A practical prioritization matrix looks like this:

Environment	Priority
Internet-facing application with jQuery <3.5.0	High
Public application processing user-controlled HTML	Critical investigation
Admin portal rendering attacker-controlled content	Critical investigation
Internal application with user-generated HTML	High
Vulnerable library present but never executed	Lower after validation
jQuery >=3.5.0	Not affected by this CVE
Static code with no attacker-controlled HTML path	Reduced exploitability, but upgrade still recommended

The important phrase is critical investigation, rather than automatically assigning every vulnerable jQuery file a Critical technical severity.

KEV tells defenders exploitation exists.

Reachability determines whether their particular application supplies the necessary conditions.

Both facts matter.

Why CVSS Medium Does Not Mean Low Priority

The vulnerability’s Medium classification can be misleading when examined outside its deployment context.

XSS typically requires victim interaction and runs inside the browser rather than immediately compromising the operating system.

Those characteristics reduce CVSS.

But consider execution inside:

administrator portal
cloud-management console
enterprise dashboard
support-agent UI
identity-management frontend
security appliance interface

JavaScript executing under an authenticated administrator’s origin may interact with powerful application functionality.

The CVE score does not know whether the victim is:

anonymous visitor

or:

global administrator

Your risk model should.

CVE-2020-11023 Also Shows the Limits of “Sanitize Everything”

One of the most useful security lessons from this vulnerability extends far beyond jQuery.

Security engineers often define a sanitization boundary:

untrusted
    ↓
sanitize()
    ↓
trusted

Real systems are more complicated.

A better model is:

untrusted input
      ↓
parser A
      ↓
sanitizer
      ↓
serializer
      ↓
framework
      ↓
parser B
      ↓
DOM

Every transformation between sanitizer and final interpretation can potentially invalidate the sanitizer’s assumptions.

This principle appears in many vulnerability families:

mutation XSS
parser differentials
DOM clobbering
URL canonicalization bugs
template injection
encoding confusion
request smuggling
path normalization vulnerabilities

The broader lesson is simple:

Security decisions must be based on the representation consumed by the final interpreter.

For browser security, that interpreter is ultimately the HTML and JavaScript execution environment.

Security Teams Should Test Data Flows, Not Just Versions

The most useful question is not:

Do we have jQuery 3.4.1?

It is:

Can attacker-controlled data reach a vulnerable jQuery HTML sink?

A mature assessment therefore looks like:

SOURCE
query parameter

     ↓

TRANSFORMATION
API response

     ↓

SANITIZATION
HTML sanitizer

     ↓

SINK
$("#result").html(value)

     ↓

LIBRARY
jQuery 3.4.1

     ↓

BROWSER
DOM parser

     ↓

IMPACT
JavaScript execution

Once security teams can construct this evidence chain, remediation priorities become much easier to justify.

Detection Rules Developers Can Add Today

Static-analysis rules can look for dangerous patterns such as:

$(selector).html(variable)

$(selector).append(variable)

while assigning lower confidence to constant strings:

$(selector).html("<span>Ready</span>")

Data-flow-aware SAST tools can go further and identify:

HTTP input
→ JavaScript variable
→ sanitizer
→ jQuery sink

For CVE-2020-11023 specifically, security teams should not automatically dismiss the path because a sanitizer appears upstream.

That is precisely the type of trust assumption the vulnerability challenged.

Post-Patch Verification

After upgrading, verify the deployed application rather than only checking the source repository.

In the browser:

jQuery.fn.jquery

should return a patched release.

Check production bundles as well.

A common failure mode looks like:

package.json: jquery 3.7.1

while the application still serves:

/assets/legacy/jquery-2.2.4.min.js

because an old file survived the build process.

Therefore verify:

source dependency
build artifact
deployed asset
runtime-loaded asset

They should all agree.

Test Third-Party Plugins After Upgrading

Old jQuery installations usually exist because old plugins depend on them.

After upgrading, test:

modal plugins
date pickers
autocomplete
dropdowns
validation libraries
legacy AJAX plugins
table libraries
CMS extensions
custom themes

The jQuery Migrate plugin can help identify compatibility problems during migration, but organizations should avoid permanently restoring security-sensitive legacy behavior merely to keep obsolete plugins alive. (jQuery)

In many cases, replacing the plugin is safer than preserving the old runtime indefinitely.

What CISA KEV Does and Does Not Tell Us

CISA KEV tells defenders something extremely important:

The vulnerability has evidence of exploitation.

It does not automatically tell us:

who is exploiting it
which organization was compromised
which payload is dominant
whether every vulnerable jQuery instance is reachable
whether exploitation always uses the same application workflow

CISA’s public January 2025 notice simply states that CVE-2020-11023 was added based on evidence of active exploitation. (GovDelivery)

Security articles should preserve that distinction.

There is no need to manufacture an APT campaign or speculative exploit chain to make this vulnerability important.

The verified facts are already sufficient.

The Bigger Lesson From CVE-2020-11023

CVE-2020-11023 is more interesting today than it was when viewed purely as a 2020 jQuery bug.

It combines several problems that modern vulnerability-management programs repeatedly encounter:

legacy dependency
+
huge historical deployment footprint
+
client-side execution
+
parser differentials
+
sanitization assumptions
+
third-party supply chains
+
medium CVSS
+
confirmed exploitation

That combination explains why the vulnerability survived long enough to eventually appear in CISA KEV.

Organizations that patched jQuery years ago have little reason for concern about this specific CVE.

Organizations still finding jQuery 1.x, 2.x or early 3.x across production systems should treat the KEV addition as a reason to investigate those assets immediately.

Frequently Asked Questions

Is CVE-2020-11023 actively exploited?

CISA added CVE-2020-11023 to the Known Exploited Vulnerabilities Catalog on January 23, 2025 based on evidence of active exploitation. (GovDelivery)

That is stronger evidence than public proof-of-concept availability alone.

Which versions of jQuery are vulnerable?

According to NVD and the official GitHub advisory:

>= 1.0.3
< 3.5.0

jQuery 3.5.0 contains the fix. (NVD)

Is jQuery 3.4.1 vulnerable?

Yes.

Because:

3.4.1 < 3.5.0

it falls within the affected range.

Is jQuery 3.5.0 vulnerable?

Not to CVE-2020-11023 according to the official advisory.

Version 3.5.0 is the patched release. (GitHub)

Is jQuery 3.7.1 vulnerable?

No, not to CVE-2020-11023.

It is newer than the patched 3.5.0 release.

Is jQuery 4.0 vulnerable?

CVE-2020-11023 was fixed long before jQuery 4.0. jQuery 4.0.0 became the current 4.x stable release in January 2026 and additionally introduced modern features including Trusted Types support. (jQuery Blog)

Does simply having an old jQuery version prove exploitable XSS?

No.

The vulnerable library proves exposure to the affected component.

Practical exploitation generally requires an appropriate application data flow in which attacker-controlled HTML reaches the vulnerable DOM manipulation functionality.

Can sanitization prevent the vulnerability?

Generic sanitization alone was not a reliable defense for the vulnerable behavior. The official advisory specifically notes that sanitized HTML could still trigger the problem when processed through affected jQuery manipulation methods. (GitHub)

The preferred solution is upgrading jQuery.

Can CSP replace the patch?

No.

CSP can reduce XSS impact and should be deployed as defense in depth, but it does not remove the vulnerable jQuery parsing behavior.

Why was a five-year-old vulnerability added to KEV?

Because KEV prioritization is based on evidence of exploitation rather than disclosure date.

CVE-2020-11023 was disclosed in 2020 but added to CISA KEV on January 23, 2025 after evidence of active exploitation became sufficient for inclusion. (GovDelivery)

Final Assessment

CVE-2020-11023 should no longer be considered merely an old Medium-severity jQuery vulnerability.

It is now an exploited legacy web vulnerability.

The technical weakness affects jQuery versions from 1.0.3 through releases earlier than 3.5.0 and involves unsafe behavior when untrusted HTML containing <option> elements reaches jQuery DOM manipulation APIs. The jQuery team addressed the vulnerability in version 3.5.0. (GitHub)

The CISA KEV designation changes the operational interpretation.

Organizations should prioritize Internet-facing and privileged applications that still load vulnerable jQuery versions, especially where user-controlled or externally sourced HTML enters .html(), .append() or related DOM-building functions.

The most important takeaway is broader than jQuery:

Sanitized input is not permanently safe.

If another component transforms the representation
before the final parser consumes it,
the security properties must be reevaluated.

CVE-2020-11023 turned browser-compatibility logic into a security boundary failure.

Years later, its addition to CISA KEV demonstrates why seemingly modest legacy frontend vulnerabilities can remain relevant long after disclosure—and why vulnerability management should combine asset discovery, reachability analysis, technical verification and real-world exploitation intelligence, rather than relying on CVSS alone. (GovDelivery)