The jQuery UI 1.13.1 vulnerabilities list contains exactly one entry — CVE-2022-31160, a cross-site scripting flaw in the checkboxradio widget fixed in 1.13.2 — while jQuery UI 1.12.1 is exposed to that one plus the three Datepicker and position-utility XSS CVEs fixed in 1.13.0. If a scan just flagged either version, the good news is that the remediation is a single, usually painless upgrade. The more useful news is that each of these CVEs only fires under specific usage patterns, so you can also determine whether the finding was ever exploitable in your application.
The four CVEs, mapped to versions
| CVE | Component | Affects | Fixed in |
|---|---|---|---|
| CVE-2021-41182 | Datepicker altField option | below 1.13.0 | 1.13.0 |
| CVE-2021-41183 | Datepicker text options (*Text) | below 1.13.0 | 1.13.0 |
| CVE-2021-41184 | .position() util, of option | below 1.13.0 | 1.13.0 |
| CVE-2022-31160 | Checkboxradio label refresh | below 1.13.2 | 1.13.2 |
So jquery ui 1.12.1 sits in the affected range of all four, and 1.13.1 — despite being a 2022-era release — still carries CVE-2022-31160. All four are cross-site scripting bugs, which puts their practical severity in the "depends entirely on how you feed the widget" category.
What each vulnerability actually requires
CVE-2021-41182 fires when untrusted input reaches the Datepicker's altField option. The option was interpreted as an HTML string, so a value like a script-bearing selector string could inject markup. Applications that hardcode altField: "#actualInput" were never exploitable; applications that built the option from a URL parameter were.
CVE-2021-41183 is the same shape spread across the Datepicker's text options — closeText, prevText, currentText, and friends. These render into the widget's DOM, so populating them from user-controlled localization data or query parameters allowed script injection. The 1.13.0 fix treats them as text.
CVE-2021-41184 lives in the .position() utility, which many other widgets call internally. Its of option accepted an HTML string as a selector, so untrusted input passed there could execute markup. Because .position() is a utility, this one can be reachable indirectly — through tooltip, menu, or autocomplete positioning — which makes "we don't use .position() directly" an incomplete defense.
CVE-2022-31160 is the reason 1.13.0 and 1.13.1 still get flagged: initializing a checkboxradio widget on an input whose label contains HTML-like text, then calling .checkboxradio("refresh"), re-parsed that label text as HTML. If the label text originated from users — a common pattern when form options are user-defined — stored XSS was possible. Fixed in 1.13.2 by escaping the label content.
None of these require an exotic attacker position. They require your code to pass attacker-influenced strings into the affected options, which is exactly the kind of dataflow question worth answering during triage instead of assuming either "definitely exploitable" or "definitely fine."
Finding jQuery UI in your estate
jQuery UI is old enough that it frequently is not in any manifest — it arrived as a copied file, inside a WordPress or admin-panel theme, or bundled with a commercial component. Fingerprint the files directly:
grep -rE "jQuery UI (Core )?[0-9]+\.[0-9]+\.[0-9]+" --include="*.js" . | sort -u
And in a live page:
jQuery.ui.version
// "1.12.1"
Check for the npm package too, since modern builds may pull it transitively:
npm ls jquery-ui jquery-ui-dist
Run both checks. It is common to find one patched npm copy and one forgotten vendored copy of 1.12.1 in the same application, and a dependency scanner that only reads package-lock.json will see just the healthy one. File-level SCA scanning closes that gap by fingerprinting what actually ships.
The upgrade path
Move to 1.13.2 at minimum; the 1.14 line is the current release train as of 2025. From 1.12.1, the 1.13 migration is mild — the notable changes are the modernized build tooling and the security-driven behavior changes themselves. Options that previously accepted HTML strings are now treated as text or CSS selectors, so if your application relied on injecting markup through altField or Datepicker text options, that code will need reworking — which is appropriate, because that reliance was the vulnerability.
npm install jquery-ui@1.13.2
For vendored copies, replace the file from the official release and re-run any theme or widget smoke tests, paying attention to Datepicker localization and custom checkboxradio labels.
If an upgrade is temporarily blocked, the interim mitigation for all four CVEs is the same: guarantee that the affected options and labels only ever receive trusted, static values, and HTML-encode any user-supplied text before it reaches a widget. That is a compensating control, not a fix — document it as such with an expiry date, a discipline we cover in our Academy guidance on managing accepted risk.
Why these old XSS bugs still matter in 2025
jQuery UI's own team declared the project in maintenance mode years ago, yet it remains embedded in enterprise admin consoles, government portals, and CMS plugins at enormous scale — IBM, Broadcom, and Informatica have all shipped security bulletins for these exact CVEs in their products. Two lessons generalize. First, UI libraries age in place: nobody rewrites a working admin screen, so the dependency outlives its maintenance window quietly. Second, XSS in a shared widget library is a multiplier — one vulnerable Datepicker pattern copied across forty internal forms is forty findings with one root cause. Fixing the library version once beats patching call sites forever.
FAQ
Is jQuery UI 1.13.1 safe to use?
Not entirely — it is affected by CVE-2022-31160, an XSS in the checkboxradio widget when labels contain user-influenced text and refresh is called. Upgrade to 1.13.2 or later to close it.
Which CVEs affect jQuery UI 1.12.1?
Four: CVE-2021-41182, CVE-2021-41183, and CVE-2021-41184 (Datepicker and .position() XSS, fixed in 1.13.0), plus CVE-2022-31160 (checkboxradio XSS, fixed in 1.13.2).
Can I patch without upgrading?
You can mitigate by ensuring the affected options — altField, Datepicker text options, .position()'s of, and checkboxradio label content — never receive untrusted input. But treat that as temporary; the upgrade to 1.13.2+ is small and permanent.
Does upgrading jQuery UI require upgrading jQuery itself?
Generally no for the 1.13 line, which supports the jQuery versions common in legacy apps. Verify your combination in a staging environment, especially if you are also on a pre-3.5 jQuery core, which has its own XSS CVEs worth clearing in the same change.