CVE-2020-11023 is a cross-site scripting (XSS) vulnerability in JQuery JQuery. CISA added it to the Known Exploited Vulnerabilities catalogue on 23 January 2025, which means attackers have used it in real attacks. JQuery contains a persistent cross-site scripting (XSS) vulnerability.
How this XSS vulnerability works
Cross-site scripting in jQuery means untrusted input can be interpreted as script in a browser context that the application did not intend. In practice, the danger is not the library name alone, but the way application code passes tainted data into DOM, HTML, or event-handling paths.
For readers tracking the underlying class rather than only the CVE, the same attack pattern appears across many web application issues. NHIMG’s Web Application Attacks Guide places XSS in the wider family of browser-side injection flaws and helps explain why seemingly small filtering mistakes become code execution in the user’s session.
Why it is dangerous in a browser-heavy application
XSS is dangerous because the payload executes with the victim’s browser trust, not the attacker’s. That can expose session data, alter page content, redirect users, trigger unwanted actions, or make a legitimate application behave as if the attacker were the user.
Persistent XSS is especially serious because the malicious content can be stored and replayed to many visitors. When the vulnerable page or component is widely reused, one injection point can become a repeated delivery mechanism for browser compromise.
Authoritative vulnerability records are the right place to confirm the record itself and its status. The CVE Program identifies the vulnerability record, while the NIST National Vulnerability Database is the place to verify the canonical entry and related metadata.
How organisations assess exposure and confirm impact
Exposure starts with inventory and dependency visibility. Teams need to know where jQuery is used, which applications bundle it, whether the affected component is reachable from users, and whether input flows into dynamic rendering paths that can be abused.
From there, validation should focus on real attack surface, not just package presence. Review whether the vulnerable code path is reachable in production, whether it is internet-facing, and whether vendor advisories or application release notes confirm that the affected usage pattern exists in your environment.
That broader process is part of normal vulnerability handling. NHIMG’s Vulnerability Management Guide is useful here because it frames exposure as a prioritisation problem, not just a scan result, and it aligns with KEV-driven remediation urgency.
Remediation, detection, and post-patch review
The first objective is to remove or neutralise the injection path. When patching or upgrading cannot happen immediately, compensating controls should reduce the chance that user-supplied content reaches script execution, and they should make exploitation harder to repeat.
Detection should look for injected markup, unexpected script execution, abnormal redirects, DOM changes, and suspicious requests or logs around the affected page. After remediation, review whether the issue was abused before the fix, because XSS often leaves little obvious infrastructure footprint.
For practical defensive patterns around browser-side injection, input handling, and output encoding, the OWASP Cheat Sheet Series remains a useful implementation reference, especially where teams need to harden the rendering path rather than simply replace a library.
Risk and Threat Considerations
Persistent XSS creates a repeatable delivery channel for browser compromise, which is why it often matters more than a one-off reflected payload. In a high-traffic application, the same stored payload can keep affecting new users until the unsafe input path or stored content is cleaned up.
Failure mechanism: An attacker gets unsanitized content into a location that the application later renders as executable browser code, so the browser runs attacker-controlled script in a trusted session.
Impact: The result can include session theft, unauthorized actions, content tampering, phishing inside the application, and exposure of data visible to the logged-in user.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | XSS is prevented by correct output encoding and sanitization. |
| V3 — Web Frontend Security | The issue manifests in browser rendering and client-side handling of untrusted content. | |
| V15 — Secure Coding and Architecture | The vulnerability reflects a design and implementation failure in handling untrusted input. | |
| Recommendation — Apply V1 controls to encode untrusted data before it reaches the browser. Review frontend rendering paths for DOM-based injection and unsafe template use. Design the application so untrusted input cannot reach executable browser contexts. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | XSS is an application security flaw that needs secure coding and validation controls. |
| CIS-7 — Continuous Vulnerability Management | The CVE is an exploitable vulnerability that must be inventoried, prioritised and remediated. | |
| Recommendation — Embed secure development checks to prevent browser-side injection flaws. Track exposed applications and remediate the vulnerable component with urgency. | ||
Practitioner Guidance
What to watch for: Treat any place where user-controlled data is reused in HTML, attributes, templates, or client-side rendering as a review point, especially if the application depends on legacy JavaScript libraries or dynamic DOM insertion.
Practitioner takeaway: The safest response is to fix the rendering path, not just the symptom. If the application can still echo untrusted input into the page, the same class of XSS can reappear through a different code path.