jQuery selector and HTML confusion enables Cross-site Scripting

jQuery before 1.9.0 is vulnerable to Cross-site Scripting (XSS) attacks. The jQuery(strInput) function does not differentiate selectors from HTML in a reliable fashion. In vulnerable versions, jQuery determined whether the input was HTML by looking for the '<' character anywhere in the string, giving attackers more flexibility when attempting to construct a malicious payload. In fixed versions, jQuery only deems the input to be HTML if it explicitly starts with the '<' character, limiting exploitability only to attackers who can control the beginning of a string, which is far less common.

• jQuery core: The record identifies jQuery before 1.9.0 as affected. The project's bug tracker assigns the issue to the core component and the 1.9 milestone; the fix is described as changing HTML detection so that the string must start with <.
• npm package jquery: The Snyk advisory for the npm package uses a broader package-specific boundary, marking versions <1.9.1 as affected and directing users to upgrade to 1.9.1 or higher. This package boundary should not automatically be treated as identical to the core jQuery boundary in the record.
• RubyGems package jquery-rails: A downstream advisory identifies versions >=2.0.1 and <2.2.0 as affected, with 2.2.0 or higher given as the package remediation.
• Other packaged distributions: The record and inspected advisories do not establish one universal boundary for every distribution, vendor backport, or integrated product. Verify the actual package and product rather than treating a fix for one branch as proof that all other branches are unaffected.

The affected component is jQuery initialization logic, specifically the jQuery(strInput) call used to distinguish CSS selectors from HTML strings. In affected versions, the HTML-detection expression could find the < character anywhere in the input, including inside a selector or other data. Attacker-controlled input could therefore be interpreted as HTML instead of a selector, creating a Cross-site Scripting condition in applications that use the result.

The fix changes the detection rule so that the HTML branch matches only when the string starts with <; the change is associated with the core component and the selector interpreted as HTML issue. Exploitation requires an application to pass attacker-controlled data to jQuery(strInput), followed by a victim processing the relevant browser flow. The available evidence does not identify a universal application sink, complete payload, or application-specific browser configuration.

The issue can be reached through a web application when attacker-controlled data is accepted and passed to jQuery(strInput). The record describes the condition as requiring no authentication, having low complexity, and requiring user interaction because a victim's browser must process the affected flow.

The record marks public exploit material as available, and the Snyk advisory states that it has a proof of concept or detailed exploitation explanation. The supplied evidence does not confirm an active campaign, a specific victim, or exploitation in a particular organization's environment. The absence of such information in the record should not be treated as proof that exploitation has never occurred.

A successful attack can cause browser input to be interpreted in a way that permits JavaScript execution within the affected web application's context. This may affect the confidentiality and integrity of data available to the origin or user session, consistent with the record's described confidentiality and integrity impact.

The issue is not identified as directly affecting availability. The required conditions include an application path that passes attacker-controlled data to jQuery(strInput) and a user who processes that path in a browser. The ultimate scope, accessible data, and possible actions depend on user permissions, origin boundaries, application controls, and other defenses; those details are not established universally by the available evidence.

A web application using an affected jQuery version may allow untrusted script to run in the application's origin when the required input flow is reachable. Possible consequences include reading or changing data available to the browser session, altering the user interface and workflow, or performing actions in the user's context, although the exact scope depends on account permissions and application design.

The issue is not described as causing direct loss of availability. The main operational concern is that old jQuery copies frequently remain inside bundled assets or downstream products, making effective-version identification and input-flow review important. The record does not provide evidence of a specific data breach or compromise, so the vulnerability should not be treated as proof that an organization has been breached.

1. Upgrade jQuery core to 1.9.0, the fix boundary confirmed by the record and the project's issue history for the selector and HTML detection change. For the npm jquery package, follow the package-specific Snyk guidance to upgrade to 1.9.1 or higher; do not assume that 1.9.0 is sufficient for every packaging format.
2. If jquery-rails is used, move out of the affected package branch according to its advisory, specifically to 2.2.0 or higher. Verify the lockfile and bundled asset so that the deployed application actually uses the remediated code.
3. Review and change flows that pass untrusted data to jQuery(strInput). When HTML parsing is intended, use an explicit parsing API or pattern appropriate to the application and review how the data is handled and neutralized; changing APIs without compatibility testing is not a complete remediation.
4. Run regression tests for selectors containing < away from the beginning of the string, user-controlled input, and existing HTML templates. Confirm that the application no longer depends on the old detection behavior.
5. If an immediate upgrade is not possible, isolate uses of the legacy jQuery copy, reduce untrusted data reaching the constructor, and prioritize replacement of the asset in the next release. Treat this as temporary risk reduction, not a substitute for the vendor or package fix.

1. Inventory every jQuery copy loaded directly, bundled into an asset, or introduced through a dependency. Determine the effective version from manifests, lockfiles, package metadata, JavaScript banners, and the content of the deployed asset itself.
2. Check the jquery package, bundled jQuery core copies, and downstream packages such as jquery-rails separately when they are present. Do not treat a filename or an unverified scanner result as proof of the effective version.
3. Search for jQuery(strInput) or equivalent call sites where the input may originate from HTTP parameters, fragments, query strings, user content, API responses, or third-party data. Prioritize flows that can place a < character into a position other than the beginning of the string.
4. Reconcile each package with its own affected and fixed boundary, because advisories for different ecosystems can use different version cutoffs.
5. Browser telemetry and Content Security Policy alerts can be reviewed as precautionary signals for unexpected script execution. The available evidence does not provide a CVE-specific IOC or log signature, and the absence of log evidence does not establish that a system is safe.