Remediation Guides

JQuery UI < 1.13.0 Multiple XSS: How to Fix CVE-2021-41184 (Nessus 156443 and 163599)

26 September 2026 8 min read

JQuery UI < 1.13.0 Multiple XSS is a Nessus finding (plugin 156443) meaning a web server hosts a jQuery UI library older than 1.13.0, which has three cross-site scripting bugs, including CVE-2021-41184. To fix it, replace every reported copy with jQuery UI 1.13.2 or later, which also clears the related plugin 163599, then rescan.

What the scanner is actually detecting

Nessus finds this remotely. It locates jQuery UI files on the web server and compares the version they report against the fixed release. Tenable states for both plugins that Nessus has not tested for the issue and relied only on the application’s self-reported version number. Nothing is exploited during the scan.

Scanner Plugin ID Finding title CVEs Fixed in
Nessus 156443 JQuery UI < 1.13.0 Multiple XSS CVE-2021-41182, CVE-2021-41183, CVE-2021-41184 1.13.0
Nessus 163599 jQuery UI < 1.13.2 XSS CVE-2022-31160 1.13.2

Both plugins sit in the CGI abuses family, and both require the Settings/ParanoidReport knowledge base item (Tenable lists “Enable paranoid mode” as a required configuration). They only report when the scan policy is set to show potential false alarms, which explains why a default scan of the same server may show nothing. A copy older than 1.13.0 normally triggers both plugins; a copy of 1.13.0 or 1.13.1 triggers only 163599.

The four bugs, as described in the jQuery UI security advisories:

  • CVE-2021-41182: the Datepicker altField option could execute code when its value came from an untrusted source. Since 1.13.0, any string is treated as a CSS selector.
  • CVE-2021-41183: the Datepicker *Text options (closeText, currentText, prevText, nextText, buttonText, appendText) accepted HTML. Since 1.13.0 they accept text only.
  • CVE-2021-41184: the of option of the .position() utility could execute code from an untrusted string, for example markup with an onerror handler. Since 1.13.0, any string is treated as a CSS selector.
  • CVE-2022-31160: when a checkboxradio widget is initialized on an input inside a label, calling .checkboxradio( "refresh" ) decodes HTML entities in the label text, so encoded markup can turn into live HTML. Fixed in 1.13.2.

Real-world risk

Tenable rates both plugins Medium (CVSS v3 base 6.1) and notes that exploit code is available. The honest reading: every one of these bugs needs application code to pass attacker-influenced data into one specific option or widget. Loading jQuery UI does not create an XSS by itself, and a site whose datepicker labels and positioning targets are hard-coded is not practically exposed.

The questions that decide real exposure are narrow. Are any of these options filled from URL parameters, database content, translation strings that editors can change, or other user-editable settings? Does any page refresh a checkboxradio whose label shows user-supplied text? If yes, the result is ordinary XSS: script running in the victim’s browser session, which matters most on admin consoles and authenticated portals. It does not give an attacker code execution on the server. At the time of writing, none of the four CVEs appears in the CISA Known Exploited Vulnerabilities catalog. Proving that no code path reaches these options across your templates and third-party plugins is usually more work than upgrading.

How to confirm it on the host

Start from the plugin output, which shows where Nessus found the library. Fetch that URL and read the banner:

curl -s https://app.example.com/js/jquery-ui.min.js | head -c 120

Full builds begin with a comment such as /*! jQuery UI - v1.12.1 - 2016-09-14, followed by an Includes: line listing the bundled modules. Individual module files, as shipped in the npm package, carry headers such as jQuery UI Datepicker 1.13.2. The scanner only reports URLs it crawled, so search the disk for every copy. On Linux:

grep -rIoE --include='*.js' 'jQuery UI( - v| [A-Za-z ]*)[0-9]+.[0-9]+.[0-9]+' /var/www | sort -u

On Windows with IIS:

Get-ChildItem -Path C:inetpub -Recurse -Include *.js |
  Select-String -Pattern 'jQuery UI( - v| [A-Za-z ]*)d+.d+.d+' -List |
  Select-Object Path, @{n='Version';e={$_.Matches[0].Value}}

In the browser, open the affected page and run jQuery.ui.version in the developer console. For Node.js projects, list every installed copy:

npm ls jquery-ui jquery-ui-dist --all

How to fix it

Pick the target version

1.13.2 is the minimum that clears both plugins. Two better targets exist:

  • 1.13.3: the last 1.13.x release. The 1.13 line requires jQuery 1.8.0 or newer, so it is the smallest step for old code.
  • 1.14.2: the current release (January 2026), tested against jQuery 1.12.4, 2.2.4, 3.6.4, 3.7.1 and 4.0.0. It removes all Internet Explorer support. Choose it when pages already run jQuery 1.12 or newer, especially if you are also upgrading jQuery core.

A file you host yourself

If the old file’s Includes: line shows only some modules, it was a custom build: rebuild the same components with the jQuery UI Download Builder. Otherwise fetch the full build under a versioned filename, together with the matching theme stylesheet:

curl -fsSL -o /var/www/app/js/jquery-ui-1.14.2.min.js https://code.jquery.com/ui/1.14.2/jquery-ui.min.js
curl -fsSL -o /var/www/app/css/jquery-ui-1.14.2.css https://code.jquery.com/ui/1.14.2/themes/base/jquery-ui.css

Point your templates at the new files and delete the old ones so they are no longer reachable. A new filename also avoids stale browser caches.

Pages that load jQuery UI from a CDN

Change the script tag and keep Subresource Integrity. The hash below is the one published on releases.jquery.com for the 1.14.2 minified build:

<script src="https://code.jquery.com/ui/1.14.2/jquery-ui.min.js"
        integrity="sha256-mblSWfbYzaq/f+4akyMhE6XELCou4jbkgPv+JQPER2M="
        crossorigin="anonymous"></script>

npm, NuGet and WebJars builds

Update the dependency, rebuild and redeploy. The scanner sees the deployed file, not your manifest.

npm install jquery-ui@1.14.2

The separate jquery-ui-dist package stops at 1.13.3; either pin it there or switch to jquery-ui, which ships dist/jquery-ui.js and dist/jquery-ui.min.js. For a transitive copy, add "overrides": { "jquery-ui": "1.14.2" } to the root package.json and test the parent package. In the Visual Studio Package Manager Console, run Update-Package jQuery.UI.Combined -Version 1.14.1 (the newest NuGet release). Java projects using WebJars should move org.webjars:jquery-ui to 1.14.2. Catching outdated libraries before deployment is the job of software composition analysis, covered in this comparison of SAST, DAST and SCA.

CMS sites and vendor products

WordPress 6.1 and later register jQuery UI 1.13.2 or newer in core, so updating core clears copies under wp-includes/js/jquery/ui/. Themes and plugins often bundle their own copy, so check each path the scanner lists and update the component that owns it. For appliances and commercial consoles, ask the vendor for a release that ships jQuery UI 1.13.2 or later; hand-edited vendor files are unsupported and get overwritten on upgrade. If no fix exists, restrict access to the interface and record a formal exception.

How to verify the fix and rescan

  1. Request the old URL from the plugin output. It should return 404, or a banner showing 1.13.2 or later.
  2. Purge the path on any CDN, reverse proxy or cache, and confirm every load-balanced node received the deployment.
  3. Hard-reload the page and confirm jQuery.ui.version returns the new version.
  4. Repeat the grep or PowerShell search and confirm no pre-1.13.2 banners remain.
  5. Rescan with the same policy, including the paranoid “show potential false alarms” setting. Without it, 156443 and 163599 never run, so their absence proves nothing.
  6. Test the widgets you use, especially Datepicker, checkboxradio, dialogs and anything relying on .position().

What can break and how to roll back

The security fixes change documented behavior, per the jQuery UI 1.13 upgrade guide:

  • Code that passed HTML to altField or to the of option to create elements now gets a selector lookup instead. Create the element first and pass it, or pass a selector.
  • Markup in buttonText, prevText and the other *Text options now displays as literal text, so icon markup in a datepicker button shows up as raw tags.
  • The private $.ui.escapeSelector was removed; use $.escapeSelector() (jQuery 3.0 and later, with a polyfill in ui/jquery-patch.js for older versions). jQuery 1.7 is no longer supported.

Moving to 1.14 adds more: $.fn._form, $.ui.ie, $.ui.safeActiveElement and $.ui.safeBlur are gone, and the 1.11 backward-compatibility API is off unless you set $.uiBackCompat = true. Old third-party plugins are the usual source of breakage.

To roll back, keep the previous file in your deployment artifacts (not in the web root) and revert the script tag or package version. Rollback restores the vulnerable code, so treat it as a short, documented step while you fix the incompatibility.

Common false positive reasons

  • Version-only detection. The file is flagged whether or not any code passes untrusted data to the affected options. That is a risk-acceptance question, not a false positive.
  • Paranoid-mode reporting. Both plugins run only in a mode that deliberately includes potential false alarms. Confirm the banner with curl before assigning work.
  • Stale caches. A CDN, reverse proxy or missed node keeps serving the old file after you upgraded.
  • Orphaned copies. Backup folders, demo pages and old theme directories still serve old files. They are reachable, so remove them rather than suppress the finding.
  • Vendor-patched builds. Some products backport fixes but keep the old banner. Get a written vendor statement before closing the finding.

FAQ

Does upgrading to jQuery UI 1.13.0 clear both findings?

No. 1.13.0 fixes CVE-2021-41182, CVE-2021-41183 and CVE-2021-41184, which clears plugin 156443. Plugin 163599 (CVE-2022-31160) needs 1.13.2 or later.

Do I have to move to jQuery UI 1.14?

No. 1.13.2 or 1.13.3 clears both plugins. 1.14 is worth it when you have dropped Internet Explorer and run jQuery 1.12 or newer.

Is there a workaround if I cannot upgrade yet?

The advisories recommend not accepting altField, *Text or of values from untrusted sources, and wrapping all non-input label content in a span for checkboxradio. Scanners still see the old version, so treat these as temporary compensating controls.

Why does the finding appear in some scans but not others?

Both plugins require paranoid reporting. Scans whose policy does not show potential false alarms never run them.

Tracking this finding across many hosts

An old jQuery UI copy often ships with a shared template or vendor product, so the same finding appears on many web servers at once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as .nessus files, and merges duplicate findings within each scanner. For Nessus findings it can re-test an individual finding after you replace the file, so closure rests on a fresh check rather than a ticket status.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles