CVE-2024-53985

What it actually does

Rails::HTML::Sanitizer 1.6.0 can fail to remove or neutralize dangerous HTML/JavaScript in specific dependency combinations: Rails 7.1.0 or later with Nokogiri earlier than 1.15.7, or Nokogiri 1.16.x earlier than 1.16.8. Because Rails applications commonly use this sanitizer to clean user-supplied rich text, comments, descriptions, profile fields, CMS content, or other HTML fragments before rendering them, the flaw can allow stored or reflected cross-site scripting when attacker-controlled markup is accepted and later displayed in a browser. Successful exploitation executes attacker-supplied JavaScript in the victim user's browser in the security context of the vulnerable application.

Why it matters to the business

If affected applications render sanitized user-generated HTML, an attacker may be able to run scripts in users' browsers, which can lead to account takeover, session theft where cookies are not adequately protected, unauthorized actions performed as a logged-in user, data exposure through the web UI, phishing inside a trusted application, and reputational impact. The current public exploitation signal is low: EPSS is 0.00581, there is no known CISA KEV listing, no ransomware association is reported, and exploit maturity is listed as none. However, Rails components are widely deployed in internet-facing applications, so organizations should still remediate during normal vulnerability management cycles, with higher priority for applications that accept and display rich text from untrusted users.

How an attack unfolds

An attacker first identifies a Rails application that uses Rails::HTML::Sanitizer 1.6.0 together with Rails 7.1.0 or later and a vulnerable Nokogiri version. They then find an input path where HTML is accepted, sanitized, stored or reflected, and later rendered to another user, such as comments, messages, profile content, support tickets, content management fields, or rich-text editors. The attacker submits specially crafted HTML intended to bypass the sanitizer under the affected Nokogiri parsing behavior. When a victim views the affected page, the browser interprets the crafted content as executable script instead of inert markup. The script then runs with the application's origin privileges and may read page content, trigger authenticated actions, modify forms, redirect users, inject phishing prompts, or attempt to exfiltrate accessible tokens or data, depending on browser protections and application controls.

How to fix it

Upgrade Rails::HTML::Sanitizer from 1.6.0 to 1.6.1 or later. The 1.6.1 fix updates the Nokogiri dependency requirement so that vulnerable Nokogiri versions are not used. Ensure Nokogiri is upgraded to 1.15.7 or later, or to 1.16.8 or later if using the 1.16.x branch. Review application lockfiles and deployed artifacts, not only declared dependency files, because vulnerable transitive versions may remain pinned in Gemfile.lock or container images. For the Git source package, use a version containing commit 5e96b19bbb934284e675109851bd82429622bb6e or a later release. If operating-system package data is relevant to an environment, ensure Ubuntu 14.04 LTS perl packages are at 5.18.2-2ubuntu1.4 or later and Ubuntu 16.04 LTS perl packages are at 5.22.1-9 or later, though the Rails sanitizer issue should primarily be remediated through the Ruby gem dependency chain. As defense in depth, apply a restrictive Content Security Policy, mark session cookies HttpOnly and Secure, use SameSite protections, avoid rendering user HTML unless required, and prefer allowlisted formatting options over arbitrary HTML.

How to confirm the fix worked

Confirm that no deployed application bundle contains rails-html-sanitizer 1.6.0 together with Rails 7.1.0 or later and Nokogiri below 1.15.7 or Nokogiri 1.16.x below 1.16.8. Check dependency manifests and lockfiles with commands such as `bundle info rails-html-sanitizer`, `bundle info nokogiri`, `bundle exec ruby -e 'require "rails-html-sanitizer"; require "nokogiri"; puts Gem.loaded_specs.values_at("rails-html-sanitizer","nokogiri").map { |s| "#{s.name} #{s.version}" }'`, and software composition analysis tools. Validate container images and production build artifacts, because CI and runtime dependencies can differ. After upgrading, run application tests around rich-text rendering and sanitizer behavior, and add regression tests that verify script-capable HTML is removed or escaped. For exposure assessment, inventory Rails applications that render user-supplied HTML and prioritize internet-facing or multi-user applications.

Typical attack path

1. Identify a Rails application that accepts user-controlled HTML or rich-text input.
2. Determine or infer that the application uses Rails::HTML::Sanitizer 1.6.0 with Rails 7.1.0 or later and a vulnerable Nokogiri version.
3. Submit crafted HTML/markup to a field that is sanitized and then displayed back to users.
4. Wait for a privileged or targeted user to view the rendered content, or trigger a reflected rendering path directly.
5. Execute JavaScript in the victim browser under the vulnerable application's origin.
6. Use the script to perform unauthorized actions, steal accessible data, modify displayed content, or redirect the user to attacker-controlled infrastructure.

How to detect it

To assess whether exploitation already occurred, review web access logs, application logs, WAF events, reverse-proxy logs, and database audit/export data for submitted HTML that looks like script execution attempts. Focus on endpoints that create or update comments, posts, messages, tickets, profile fields, CMS pages, product descriptions, markdown/rich-text fields, or any feature that stores and renders user content. Look for payloads containing script tags, JavaScript URLs, browser event-handler attributes, SVG or MathML-based execution vectors, unusual encoded HTML entities, base64-encoded JavaScript, DOM-manipulation strings, or external attacker-controlled script references. Correlate suspicious content submissions with subsequent page views by other users, unexpected redirects, abnormal authenticated actions, changes to account settings, new API keys or tokens, suspicious administrative actions, or reports of unexpected pop-ups and login prompts. Browser-side XSS may leave limited server-side evidence, so combine content searches with CSP violation reports, WAF alerts, endpoint telemetry from administrator workstations, and authentication/session anomaly logs. No specific threat actor or active campaign is currently associated with this vulnerability in the provided data.

• rails-html-sanitizer 1.6.0
• nokogiri 1.15.0
• nokogiri 1.15.1
• nokogiri 1.15.2
• nokogiri 1.15.3
• nokogiri 1.15.4
• nokogiri 1.15.5
• nokogiri 1.15.6
• nokogiri 1.16.0
• nokogiri 1.16.1
• nokogiri 1.16.2
• nokogiri 1.16.3
• nokogiri 1.16.4
• nokogiri 1.16.5
• nokogiri 1.16.6
• nokogiri 1.16.7
• <script
• </script
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• <svg
• </svg
• <math
• </math
• xlink:href=
• data:text/html
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• String.fromCharCode
• window.location
• location.href
• new Image().src
• Content-Security-Policy-Report-Only
• violated-directive

What your security team should do

• Inventory Rails applications and dependency lockfiles for rails-html-sanitizer 1.6.0, Rails 7.1.0 or later, and vulnerable Nokogiri versions below 1.15.7 or 1.16.x below 1.16.8.
• Upgrade rails-html-sanitizer to 1.6.1 or later and ensure Nokogiri is at 1.15.7 or later, or 1.16.8 or later on the 1.16 branch.
• Prioritize remediation for applications that accept and render untrusted rich-text or HTML content, especially internet-facing, customer-facing, administrative, messaging, support, forum, CMS, and profile features.
• Search application data and logs for suspicious HTML/JavaScript payloads submitted to user-content fields, particularly payloads that include event handlers, SVG/MathML tags, encoded script fragments, or external JavaScript URLs.
• Deploy or tighten Content Security Policy to reduce the impact of any missed XSS path, avoiding unsafe-inline where practical and restricting script-src to trusted origins.
• Confirm cookies and sensitive tokens are protected with HttpOnly, Secure, and SameSite attributes to limit theft through browser-executed script.
• Add sanitizer regression tests to CI so future dependency changes do not reintroduce unsafe rendering behavior.
• Because this vulnerability is not currently in KEV and has low EPSS, handle it as a normal-priority patch unless the affected application exposes high-risk user-generated content workflows or privileged-user viewing paths.