CVE-2021-41183 is a cross-site scripting (XSS) vulnerability in jQuery UI, affecting the Datepicker widget in every version before 1.13.0. Several of the widget's *Text options — including closeText, currentText, prevText, nextText, appendText, and buttonText — rendered their values as HTML instead of plain text. If any of those values came from an untrusted source, an attacker could inject markup that executed script in the victim's browser.
It is rated Medium severity. The fix landed in jQuery UI 1.13.0, released in October 2021, which changed the widget so those option values are always treated as pure text.
What the vulnerability does
The Datepicker widget exposes a set of *Text options that control the labels shown on its navigation controls and buttons. Before 1.13.0, the widget inserted those strings into the DOM without escaping them. That is fine when the values are hardcoded literals. It becomes a problem the moment any of them is populated from data an attacker can influence.
Consider a page that localizes the Datepicker using a value pulled from a URL parameter or an API response:
// Vulnerable pattern: untrusted value flows into a *Text option
$("#date").datepicker({
closeText: userSuppliedLabel // rendered as HTML in versions < 1.13.0
});
If userSuppliedLabel contains something like an <img> tag with an onerror handler, the browser parses it as HTML and runs the handler. That gives the attacker script execution in the page's origin, which is enough for session hijacking, credential theft, or actions taken on behalf of the logged-in user. This is a textbook DOM-based XSS: the sink is a library option that developers reasonably assumed was text-only.
Who is affected
You are exposed if you load a jQuery UI build below 1.13.0 and you pass any Datepicker *Text option a value that originates from user input, a query string, cookies, or any other source outside your control. Purely static labels are not exploitable in practice, but relying on "we always hardcode these" is fragile — a future refactor that wires one of those options to dynamic content reopens the hole silently.
Because jQuery UI is old and extremely widely bundled, this CVE still shows up constantly in scans of legacy front ends, admin panels, and vendored JavaScript. It is frequently reported alongside its sibling advisories in the same jQuery UI release (the checkbox radio and dialog title XSS issues fixed in the same version).
Confirming your exposure
Find the actual jQuery UI version on the page or in your bundle. If you install via npm:
npm ls jquery-ui
Or grep the vendored file for its version banner:
grep -m1 "v1\." jquery-ui.min.js
Anything below 1.13.0 is the affected code. Front-end libraries are easy to lose track of because they are often copied into a vendor/ folder years ago and never revisited, which is exactly where a dependency scanner helps — it flags the vulnerable jquery-ui version whether it came from a package manager or a checked-in file.
How to fix CVE-2021-41183
Upgrade jQuery UI to 1.13.0 or later. Via npm:
npm install jquery-ui@^1.13.0
If you serve a vendored copy, replace the file with the 1.13.0+ distribution and confirm the version banner updated. After 1.13.0, the widget treats *Text values as pure text, so embedded HTML tags are shown literally rather than parsed — the XSS payload is neutralized at the source.
If an immediate upgrade is not possible, reduce the risk by never passing untrusted data into any Datepicker *Text option, and escape or strictly allowlist any value that must be dynamic:
function escapeHtml(s) {
return s.replace(/[&<>"']/g, c => ({
"&": "&", "<": "<", ">": ">",
'"': """, "'": "'"
}[c]));
}
$("#date").datepicker({ closeText: escapeHtml(userSuppliedLabel) });
Treat that as a stopgap. Upgrading is the durable fix because it closes every affected option at once, not just the one you remembered.
Reducing your XSS surface generally
The lesson behind this CVE is that library options are sinks too. Data flowing into a widget config deserves the same distrust as data flowing into innerHTML. A few practices help:
- Keep a Content Security Policy that blocks inline event handlers, so an injected
onerrorcannot run even if markup slips through. - Audit where user input reaches third-party widget configuration, not only obvious DOM writes.
- Scan front-end dependencies in CI so an outdated
jquery-uifails the build. The same software composition analysis that watches your back end should watch the browser bundle.
FAQ
Which jQuery UI version fixes CVE-2021-41183?
Version 1.13.0, released in October 2021, and any later release. It changes the Datepicker so *Text option values are always rendered as text rather than HTML.
Is CVE-2021-41183 exploitable if my labels are hardcoded?
Not in practice — the flaw requires an untrusted value to reach one of the *Text options. But hardcoding is a fragile control, since a later change could wire dynamic data into those options. Upgrading removes the risk permanently.
What severity is CVE-2021-41183?
It is rated Medium. The impact is client-side script execution (XSS) in the context of the affected page, which can enable session hijacking or credential theft.
Can I mitigate without upgrading?
Yes, by escaping or allowlisting any dynamic value passed to a Datepicker *Text option and enforcing a strict CSP. This is a temporary measure; upgrading to 1.13.0+ is the real fix.