CVE-2026-128069: 
Ruby Analyse et atténuation de la vulnérabilité

CVE-2026-128069 is a race condition-induced Cross-Site Scripting (XSS) vulnerability in the rails-html-sanitizer gem used by Rails applications. Both the HTML4 and HTML5 variants of Rails::HTML::SafeListSanitizer share a single Rails::HTML::PermitScrubber instance across concurrent sanitize calls without synchronization, allowing one call's allowlist to bleed into another's. All versions of rails-html-sanitizer before 1.7.2 are affected; version 1.7.2 contains the fix. It carries a CVSS v3.1 base score of 4.7 (Medium) (GitHub Advisory, GHSA). The vulnerability was reported by hiumee via HackerOne, first disclosed in the repository on November 2, 2026, and published to the GitHub Advisory Database on November 13, 2026.

The root cause is a race condition (CWE-362) combined with improper neutralization of user input (CWE-79). SafeListSanitizer initializes a single shared PermitScrubber instance and mutates its tags and attributes properties on every sanitize call without any thread synchronization. Because Action View memoizes one SafeListSanitizer per helper module, all concurrent requests in a multi-threaded server (e.g., Puma) share the same scrubber object. If two concurrent calls use different allowlists — one permissive (e.g., allowing <script> or event-handler attributes) and one strict — their assignments to the shared scrubber can interleave, causing the strict call to be executed with the permissive allowlist and emitting unsanitized HTML (GHSA, GitHub Issue #228). The fix, committed in 15f764c, constructs a new PermitScrubber per scrub call rather than reusing a shared instance.

Successful exploitation allows an attacker to bypass HTML sanitization in a multi-threaded Rails application, causing malicious <script> tags or event-handler attributes (e.g., onerror, onload) to pass through a sanitizer that was intended to strip them. The resulting unsanitized output, when stored or rendered to other users, constitutes a stored or reflected XSS vector that can lead to session hijacking, credential theft, or unauthorized actions performed on behalf of victims. Confidentiality and integrity are both assessed as low impact per CVSS, with no availability impact; however, the scope is changed, meaning the XSS can affect users beyond the directly targeted component (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity — the attacker must be able to trigger concurrent sanitize calls with differing allowlists in a multi-threaded environment, and user interaction is required for the XSS payload to execute (GitHub Advisory). No threat actor attribution has been reported.

1. Identify a vulnerable target: Locate a multi-threaded Rails application (e.g., running on Puma) using rails-html-sanitizer < 1.7.2 that has at least two code paths calling sanitize with different tags: or attributes: options.
2. Identify a permissive sanitize path: Find or trigger an application endpoint that calls sanitize with a permissive allowlist — one that includes script tags or event-handler attributes such as onerror.
3. Craft a malicious payload: Prepare an HTML payload containing a <script> tag or event-handler attribute (e.g., <img src=x onerror=alert(document.cookie)>) intended to be submitted to a strict-sanitization endpoint.
4. Race the concurrent calls: Send simultaneous HTTP requests — one to the permissive endpoint and one submitting the malicious payload to the strict endpoint — so that the PermitScrubber's tags and attributes assignments interleave. The strict call reads the permissive allowlist after the permissive call has set it but before it resets.
5. Achieve XSS: If the race is won, the strict sanitization call emits the malicious script or attribute unchanged. If this output is stored (e.g., in a database) and later rendered to other users, the XSS payload executes in their browsers, enabling session theft or other client-side attacks (GHSA, GitHub Issue #228).

• Logs: Application logs showing concurrent requests to endpoints with differing sanitization configurations arriving within milliseconds of each other; unexpected <script> tags or event-handler attributes (e.g., onerror=, onload=) appearing in stored content that should have been sanitized.
• File System / Database: Stored HTML content in the database containing <script> elements or inline event handlers in fields that are subject to strict sanitization policies.
• Network: Outbound connections from user browsers to attacker-controlled domains following rendering of stored content; unusual JavaScript execution errors in browser console logs reported by users.
• Application Behavior: User reports of unexpected JavaScript dialogs or redirects when viewing content submitted by other users on pages that apply HTML sanitization.

Upgrade rails-html-sanitizer to version 1.7.2 or later, which constructs a new PermitScrubber per sanitize call, eliminating the shared mutable state (v1.7.2 Release). If an immediate upgrade is not possible, two workarounds are available: (1) use the same allowlist for every sanitize call throughout the application, or (2) pass a per-call scrubber: option (a freshly constructed Rails::HTML::PermitScrubber with tags= and attributes= set) instead of using the tags: and attributes: keyword options (GitHub Advisory). Applications that are single-threaded or use a single uniform allowlist everywhere are not affected and do not require immediate action.

The vulnerability was originally reported by researcher OskarEichler in GitHub Issue #228 on August 30, 2026, with a detailed root cause analysis and a proposed source fix. Rails maintainer flavorjones acknowledged the report the following day, noting awareness of the issue and scheduled remediation time (GitHub Issue #228). The fix was implemented by Mike Dalessio and released as part of version 1.7.2 on November 2, 2026. The original HackerOne report (reference #3585784) was credited to researcher hiumee (GHSA).