Cross-site scripting in jquery jQuery can execute untrusted code

In jQuery starting with 1.12.0 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e..html(),.append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

The CNA product facts identify jQuery as affected in >= 1.12.0, < 3.5.0. jQuery 3.5.0 is the confirmed patched release for the library. The GitHub advisory also maps downstream packages to separate boundaries: jquery-rails < 4.4.0, patched in 4.4.0; maximebf/debugbar < 1.19.0, patched in 1.19.0; and org.webjars.npm:jquery >= 1.12.0, < 3.5.0, patched in 3.5.0. The supplied evidence also contains NVD CPE enrichment beginning at 1.2, which is broader than and not fully consistent with the CNA range, so the status of jQuery 1.2.x through 1.11.x is not confirmed by the CNA product facts.

Legacy jQuery htmlPrefilter used a regular expression to rewrite XHTML-like self-closing tags before the string was processed by DOM manipulation methods. The jQuery team documented that edge cases in this rewrite could mutate HTML that had already been sanitized, allowing untrusted code to execute when the resulting string reached methods such as .html() and .append(). The patch changes htmlPrefilter to return its input unchanged, removing the risky rewrite step. Exploitability therefore depends on an application passing user-controlled or otherwise untrusted HTML through the affected processing path; the exact application route and payload are not established by the available evidence. The supplied record supports network reachability, no required privileges, and required user interaction.

• The issue is reachable over the network when a web application passes untrusted HTML into affected DOM manipulation methods.
• The attacker does not need authenticated privileges, but a user must interact with or load the affected page through a suitable application flow.
• The CNA characterizes attack complexity as high, while another assessment in the supplied record characterizes it as low. Practical exploitability depends on how the application receives and passes HTML.
• The normalized record marks public exploit material as available, but it does not name a specific exploit, campaign, victim, or confirmed in-the-wild incident.

When the required processing conditions are present, attacker-controlled HTML can result in script execution in the web page's context. Consequences may include reading data accessible to the page, changing page content or state, and performing actions within the permissions of the interacting user. The supplied record indicates that scope can extend from the library into the consuming application and does not indicate an availability impact; the issue does not by itself establish server-side code execution. Exposure is limited to applications that actually pass untrusted HTML through the relevant processing paths.

• Malicious script may run in the browser context of an affected page and may be able to read data accessible to that page or modify its visible state.
• Depending on the page's permissions and the user's session, the executed code may perform actions on behalf of the user within the application's scope.
• Organizations may need to investigate vendored or bundled jQuery copies across multiple applications and test compatibility changes introduced by the upgrade.
• The available evidence does not establish a specific breach, data loss event, or service outage. Actual consequences depend on the data and permissions available to the page using jQuery.

1. Upgrade jQuery to 3.5.0, the confirmed patched release, after testing changes related to self-closing tags and invalid HTML handling.
2. Check vendored, bundled, CDN-delivered, and downstream copies. Updating a dependency manifest alone is not sufficient if deployed assets still contain an older jQuery copy.
3. If an upgrade is not yet possible, the advisory provides a workaround by setting jQuery.htmlPrefilter = function( html ) { return html; };. The advisory describes this as applicable to versions that support the override, at least jQuery 1.12 or 2.2 and newer, and it must be tested in the application.
4. Do not restore the legacy htmlPrefilter as a substitute security fix. The jQuery upgrade guide warns that restoring the old behavior loses the security fix and that regular HTML sanitizing may not be sufficient.
5. After the change, review sanitizers and every flow that passes HTML to DOM manipulation methods, then run regression tests for components that depend on self-closing tags.

• Inventory deployed JavaScript assets, SBOMs, lockfiles, and dependency manifests to identify jQuery loaded directly or bundled into an application.
• Check related package and deployment identifiers such as jquery, components/jquery, jquery-rails, maximebf/debugbar, and org.webjars.npm:jquery, then compare the deployed versions with the affected boundaries.
• Review source for .html(), .append(), and other DOM manipulation methods receiving HTML from requests, user input, or external sources, including HTML that has passed through a sanitizer.
• Check for assignments to jQuery.htmlPrefilter or code that restores the legacy prefilter, because these changes can affect whether the security fix is effective and how jQuery parses HTML.
• CSP violation reports and browser telemetry can be reviewed for unexpected script execution as precautionary monitoring. No specific indicator of compromise is established in the available evidence, and absence of log evidence does not prove safety.