CVE-2024-53987

What it actually does

CVE-2024-53987 is a cross-site scripting issue in Rails::HTML::Sanitizer 1.6.0 when used with Rails 7.1.0 or later under certain configurations. The sanitizer may fail to neutralize specific attacker-controlled HTML or markup constructs before they are rendered into a browser. If an application relies on the affected sanitizer to clean untrusted user input, a malicious payload can survive sanitization and execute JavaScript in the context of another user’s browser session.

Why it matters to the business

Successful exploitation can allow attackers to run unauthorized actions as affected users, steal session-related data accessible to browser JavaScript, alter page content, redirect users to phishing pages, or abuse trusted application workflows. The risk is highest for Rails applications that accept and display user-generated HTML, comments, profile fields, rich-text content, support tickets, messages, or CMS-style content. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so it is generally a patch-prioritized application security issue rather than an emergency internet-wide exploitation event.

How an attack unfolds

An attacker first identifies a Rails application that accepts user-controlled HTML or rich-text input and later displays that content to other users after processing it with Rails::HTML::Sanitizer 1.6.0 on Rails 7.1.0 or later. The attacker crafts an HTML payload that bypasses the vulnerable sanitizer behavior and submits it through a normal application feature such as a comment, message, profile field, document body, or administrative content editor. When another user views the stored or reflected content, the browser interprets the remaining malicious markup and executes attacker-supplied JavaScript in the victim’s authenticated application context. Depending on the application’s security controls, the script may perform actions on behalf of the victim, exfiltrate data available to the page, modify displayed content, or redirect the user to attacker-controlled infrastructure.

How to fix it

Upgrade Rails::HTML::Sanitizer from version 1.6.0 to version 1.6.1 or later. For source-based deployments, update to a version that includes the upstream fix, including rails/rails-html-sanitizer commit 5e96b19bbb934284e675109851bd82429622bb6e or a later release containing it. Regenerate and redeploy dependency lockfiles so production uses the fixed sanitizer version, not only an updated manifest. If operating system packages are relevant to the deployment inventory, apply vendor updates listed for the affected packages, including node-semver 2.1.0-2ubuntu0.0.1~esm1 for Ubuntu Pro 14.04 ESM, node-semver 2.1.0-2ubuntu0.1~esm1 for Ubuntu Pro 16.04 ESM, and node-semver 5.4.1-1 for Ubuntu 18.04 LTS; however, application owners should specifically verify the Rails::HTML::Sanitizer gem version because this CVE is centered on that library. As defense in depth, enforce contextual output encoding, use a restrictive Content Security Policy, mark session cookies HttpOnly and SameSite where possible, validate rich-text inputs against a narrow allowlist, and review any custom sanitizer configuration or allowlisted tags and attributes.

How to confirm the fix worked

Confirm that deployed applications no longer include Rails::HTML::Sanitizer 1.6.0 and instead resolve to 1.6.1 or later. Check Gemfile.lock, software composition analysis output, container image dependency inventories, and runtime package listings. For Ruby applications, validate with commands such as `bundle info rails-html-sanitizer`, `bundle list | grep rails-html-sanitizer`, or inspection of `Gemfile.lock` for `rails-html-sanitizer (1.6.0)`. Confirm Rails versions are reviewed where Rails 7.1.0 or later is in use. Run application regression tests for rich-text rendering and sanitizer behavior, including known benign formatting and malicious XSS test payloads, to ensure dangerous markup is removed or encoded. After deployment, verify production artifacts were rebuilt and restarted so the fixed dependency is actually loaded at runtime.

Typical attack path

1. Identify a Rails application feature that accepts user-supplied HTML or rich-text content.
2. Determine that the application uses Rails::HTML::Sanitizer 1.6.0 with Rails 7.1.0 or later, or infer exposure by testing sanitizer behavior.
3. Craft an XSS payload designed to survive the vulnerable sanitization path.
4. Submit the payload through an input field, API endpoint, content editor, messaging function, or other user-generated content workflow.
5. Wait for another user, moderator, administrator, or customer to view the affected content.
6. Execute JavaScript in the victim’s browser under the trusted application origin.
7. Use the victim’s browser context to perform unauthorized actions, harvest accessible data, alter page content, or redirect the victim.

How to detect it

To assess prior exploitation, focus on application features that store or reflect user-controlled HTML. Review web server, application, API gateway, CDN, and WAF logs for requests containing XSS payloads submitted to create, update, comment, message, profile, rich-text, search, or content-management endpoints. Inspect stored user-generated content created while the vulnerable version was deployed for script tags, event-handler attributes, suspicious SVG or MathML elements, JavaScript URLs, data URLs, encoded HTML entities, and obfuscated strings. Correlate suspicious content submissions with subsequent victim page views, unusual account actions, changes to profile or security settings, unexpected administrative actions, or outbound requests to unfamiliar domains from client-side telemetry if available. Dependency and build logs should be checked for evidence that rails-html-sanitizer 1.6.0 was included in production artifacts. There are no public threat actors or KEV exploitation campaigns associated with this CVE in the provided data, so detection should be behavior- and payload-focused rather than actor-specific.

• rails-html-sanitizer (1.6.0)
• rails-html-sanitizer-1.6.0
• Gemfile.lock: rails-html-sanitizer (1.6.0)
• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• data:text/html
• onerror=
• onload=
• onclick=
• onmouseover=
• <svg
• %3Csvg
• <math
• %3Cmath
• document.cookie
• localStorage
• sessionStorage
• eval(
• alert(
• prompt(
• confirm(
• String.fromCharCode
• atob(
• fetch(
• XMLHttpRequest
• new Image().src

What your security team should do

• Inventory Rails applications that use Rails 7.1.0 or later and accept/display user-generated HTML or rich-text content.
• Prioritize upgrading rails-html-sanitizer 1.6.0 to 1.6.1 or later in internet-facing, multi-user, administrative, support, messaging, CMS, and customer-content workflows.
• Search source repositories, lockfiles, SBOMs, container images, and dependency scanners for `rails-html-sanitizer (1.6.0)`.
• Review custom sanitizer allowlists, rich-text rendering helpers, and any use of raw HTML rendering to ensure untrusted content is not bypassing sanitization entirely.
• Deploy or tighten Content Security Policy to reduce the impact of any residual XSS, avoiding unsafe-inline where feasible.
• Review recent user-generated content for suspicious script, event-handler, SVG, MathML, data URI, or encoded HTML payloads submitted before patching.
• Add security tests that submit malicious HTML through rich-text inputs and verify rendered output does not execute script.
• Monitor application and WAF logs for XSS probing patterns, especially against endpoints that create or update persistent user-visible content.