CVE-2024-53989

What it actually does

CVE-2024-53989 is a cross-site scripting vulnerability in Rails::HTML::Sanitizer 1.6.0 when used with certain configurations of Rails 7.1.0 or later. The sanitizer may fail to neutralize unsafe HTML or script-bearing markup in specific cases, allowing attacker-supplied content that is expected to be cleaned to instead be rendered by a victim’s browser as executable script. The impact depends on where sanitized content is displayed, but successful exploitation can allow execution of JavaScript in the security context of the affected web application.

Why it matters to the business

Applications that rely on the affected sanitizer version to safely display user-generated or externally supplied HTML may expose users and administrators to browser-based attacks. Consequences can include account takeover, unauthorized actions performed as the victim, theft of sensitive data visible in the browser, session compromise if cookies or tokens are accessible, phishing within the trusted application interface, and reputational damage. EPSS is currently low and there is no CISA KEV listing or known ransomware association, but because Rails components are widely used in internet-facing applications, affected deployments should still be remediated during normal patch cycles, with priority increased for applications that render rich user content.

How an attack unfolds

An attacker first identifies an application built on Rails 7.1.0 or later that uses Rails::HTML::Sanitizer 1.6.0 to clean HTML before rendering it back to users. The attacker then submits crafted HTML through an input path that permits markup, such as comments, profiles, content management fields, messages, tickets, or any feature that stores or reflects sanitized rich text. Due to the sanitizer flaw under certain configurations, the malicious payload is not fully removed or encoded. When another user views the affected page, the browser interprets the payload as executable script in the context of the legitimate application. The script can then read page data, trigger authenticated actions, alter displayed content, redirect the user, capture input, or attempt to exfiltrate browser-accessible tokens. No public exploit maturity is reported in the provided data, so exploitation would likely require application-specific payload tuning and a reachable injection point.

How to fix it

Upgrade Rails::HTML::Sanitizer from version 1.6.0 to version 1.6.1 or later. For source-based dependency tracking, the provided fixed git version is rails/rails-html-sanitizer commit 5e96b19bbb934284e675109851bd82429622bb6e. Confirm that dependency lockfiles and deployed artifacts no longer resolve to 1.6.0. If immediate upgrade is not possible, reduce exposure by disabling or restricting user-supplied HTML rendering, using strict allowlists for tags and attributes, encoding untrusted output by default, avoiding dangerous URL schemes, and applying a restrictive Content Security Policy that blocks inline script execution. These mitigations reduce risk but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm the installed dependency version in dependency manifests, lockfiles, software composition analysis results, and running application images. For Ruby applications, check Gemfile.lock or equivalent dependency inventory for rails-html-sanitizer and verify it resolves to 1.6.1 or later, not 1.6.0. If using a git-sourced dependency, verify the deployed revision includes commit 5e96b19bbb934284e675109851bd82429622bb6e or a later fixed commit. Rebuild and redeploy application artifacts after updating dependencies, then re-run application security tests for rich-text input and output encoding. Validate that known XSS test payloads are encoded or removed before rendering, and that Content Security Policy headers are present where feasible.

Typical attack path

1. Identify a Rails application that renders user-supplied or externally supplied HTML after sanitization.
2. Determine or infer that the application is using Rails::HTML::Sanitizer 1.6.0 with Rails 7.1.0 or later and an affected sanitizer configuration.
3. Find an input surface that accepts rich text or HTML, such as comments, profile fields, messages, CMS content, support tickets, or embedded descriptions.
4. Submit a crafted XSS payload designed to bypass the affected sanitizer behavior.
5. Wait for the payload to be rendered to another user, privileged user, or administrator.
6. Execute JavaScript in the victim’s browser within the application’s origin.
7. Use the script to steal browser-accessible data, perform actions as the victim, inject phishing UI, redirect traffic, or establish further client-side persistence where possible.

How to detect it

To assess possible prior exploitation, review logs and stored content for suspicious HTML submitted to fields that are later rendered to users. Useful sources include application request logs, web server access logs, WAF events, audit logs for content creation or editing, database exports of user-generated rich text, error monitoring platforms, CSP violation reports, and browser-side telemetry if collected. Focus on inputs containing script execution patterns, HTML event handler attributes, JavaScript URLs, encoded or obfuscated markup, SVG or MathML-based payloads, iframe/object/embed tags, suspicious redirects, or references to external attacker-controlled domains. Correlate suspicious submissions with subsequent page views by other users, especially administrators, followed by unusual account actions, profile changes, permission changes, outbound connections, or authentication anomalies. There are no universally reliable file, process, or registry indicators for this vulnerability because exploitation is application-content based and payloads are attacker-controlled.

• <script
• </script
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• <iframe
• <object
• <embed
• <svg
• <math
• srcdoc=
• data:text/html
• document.cookie
• document.location
• window.location
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• String.fromCharCode
• &#x
• %3Cscript
• %3Csvg
• %3Ciframe

What your security team should do

• Inventory Rails applications and libraries that include rails-html-sanitizer, prioritizing internet-facing applications and systems that render user-generated rich text.
• Patch affected deployments by upgrading rails-html-sanitizer 1.6.0 to 1.6.1 or later, or to a revision containing commit 5e96b19bbb934284e675109851bd82429622bb6e.
• Search dependency manifests, lockfiles, container images, build artifacts, and SCA tooling for rails-html-sanitizer version 1.6.0.
• Prioritize remediation for applications running Rails 7.1.0 or later with comments, messaging, CMS, profile, ticketing, forum, or administrative review features that display user-supplied HTML.
• Deploy or tighten Content Security Policy to reduce exploitability, especially by disallowing unsafe-inline scripts where practical.
• Review recent submissions to rich-text fields for suspicious HTML, event handlers, script-like payloads, encoded JavaScript, SVG payloads, and unusual URL schemes.
• Add regression tests for sanitizer behavior around allowed tags, attributes, URL protocols, SVG/MathML content, malformed HTML, and encoded payloads.
• Monitor for client-side attack symptoms such as unusual redirects, unauthorized user actions following page views, unexpected script errors, and reports of suspicious UI changes.