CVE-2026-33170

What it actually does

This flaw affects Ruby on Rails Active Support's ActiveSupport::SafeBuffer handling. In vulnerable versions before 8.1.2.1, 8.0.4.1, and 7.2.3.1, SafeBuffer#% can return a newly formatted buffer that incorrectly remains marked as HTML-safe after the original SafeBuffer was modified in place, such as with gsub!. If untrusted input is inserted through this formatting path, ERB may skip its normal HTML escaping because the value reports html_safe? == true. The result is a potential cross-site scripting condition where attacker-controlled HTML or JavaScript can be rendered in a user's browser.

Why it matters to the business

Applications using affected Rails versions may unintentionally render attacker-supplied script content in pages viewed by users. Successful exploitation can lead to account takeover of affected user sessions, unauthorized actions performed as victims, phishing within the trusted application, data exposure visible to the victim, or reputational harm. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, but Rails is widely used and vulnerable code paths may be embedded in many downstream applications, so patching should be prioritized during normal security maintenance and accelerated for internet-facing applications that render user-controlled content.

How an attack unfolds

An attacker first identifies an application page that incorporates user-controlled input into server-rendered HTML using a vulnerable ActiveSupport::SafeBuffer pattern: a buffer is marked or treated as safe, modified in place, and then formatted with the % operator using untrusted arguments. The attacker submits a crafted payload containing HTML or JavaScript, for example through a profile field, comment, search parameter, message, or other reflected or stored input location. When the Rails application renders the affected template or helper, SafeBuffer#% returns output that is incorrectly still considered HTML-safe. ERB therefore does not escape the attacker's payload. When another user, or in some cases the attacker, views the affected page, the browser executes the injected script in the context of the vulnerable application. The attacker can then steal session-adjacent data accessible to JavaScript, perform actions as the victim, modify page content, or redirect the user to malicious workflows, subject to browser protections and the application's cookie and Content Security Policy configuration.

How to fix it

Upgrade Rails/Active Support to a patched version: 8.1.2.1 or later for the 8.1 branch, 8.0.4.1 or later for the 8.0 branch, or 7.2.3.1 or later for the 7.2 branch. If using Bundler, update the rails and activesupport gems according to the supported branch and redeploy the application. If immediate upgrade is not possible, review templates, helpers, view components, and library code for SafeBuffer objects that are mutated in place and later formatted with % using untrusted values. Avoid marking strings as html_safe unless they are constant, trusted, and fully controlled by the application. Prefer Rails escaping helpers such as h(), sanitize() with an allowlist, safe_join() for known-safe fragments, and explicit escaping before interpolation. Strengthen defense in depth with a restrictive Content Security Policy, HttpOnly and SameSite cookies, and output-encoding tests for user-controlled fields.

How to confirm the fix worked

Confirm the runtime Active Support version is patched by checking Gemfile.lock, bundle info activesupport, or the deployed artifact's gem inventory. Validate that the resolved activesupport version is 8.1.2.1 or later, 8.0.4.1 or later, or 7.2.3.1 or later, depending on the Rails branch. Run the application test suite, especially view/helper/component tests that render user-controlled content. Add regression tests with representative XSS payloads to confirm they are escaped when passed through formatting paths. Static review should search for html_safe, SafeBuffer, gsub!, sub!, tr!, replace, concat, and % formatting combinations in view-layer code. Dynamic validation can include rendering pages with benign payloads such as <script>alert(1)</script> or <img src=x onerror=alert(1)> in a non-production environment and verifying the output is HTML-escaped rather than executable.

Typical attack path

1. Find a Rails application running a vulnerable Active Support version before 8.1.2.1, 8.0.4.1, or 7.2.3.1.
2. Identify a page, helper, component, or template that formats a mutated SafeBuffer with untrusted input using the % operator.
3. Submit a crafted HTML or JavaScript payload through a parameter, form field, stored content field, or other user-controllable input source.
4. Trigger rendering of the vulnerable server-side template or helper.
5. Rely on the incorrect html_safe? state to bypass ERB auto-escaping.
6. Have a victim load the affected page or response.
7. Execute attacker-controlled script in the victim's browser within the application's origin.

How to detect it

This vulnerability does not produce a universal host-level indicator because exploitation depends on application-specific rendering paths. To determine whether exploitation may have occurred, review web server, reverse proxy, CDN/WAF, and application logs for submitted input containing HTML tags, event handlers, JavaScript URLs, encoded script payloads, or template-breaking characters in parameters or fields that are reflected or stored and later rendered. Focus on endpoints that accept comments, profile data, messages, names, search terms, rich text, customization fields, or administrative content. Correlate suspicious submissions with subsequent page views by other users, especially privileged users. Review browser-side error telemetry, CSP violation reports, WAF alerts, and application security monitoring for blocked or executed inline script. If stored content is supported, inspect recently created or modified user-controlled records for script tags, SVG payloads, image error handlers, iframe tags, JavaScript URLs, and heavily encoded HTML. Also review application source and deployment history to determine whether vulnerable SafeBuffer mutation and % formatting patterns existed during the suspected exploitation window.

What your security team should do

• Inventory Rails applications and libraries that include Active Support and identify versions older than 8.1.2.1, 8.0.4.1, or 7.2.3.1.
• Prioritize internet-facing applications, applications with user-generated content, and administrative portals where XSS could lead to privileged actions.
• Patch or rebuild affected applications with a fixed Active Support version and redeploy from trusted artifacts.
• Search application code for risky SafeBuffer and html_safe usage, especially in helpers, partials, view components, presenters, and custom rendering libraries.
• Add automated dependency scanning rules to fail builds that resolve vulnerable activesupport versions.
• Add regression tests for output escaping around user-controlled input in server-rendered pages.
• Review and harden Content Security Policy to reduce the impact of any residual XSS paths.
• Hunt recent web and application logs for suspicious script-like payloads submitted to parameters or content fields that are later rendered to users.
• If suspicious payloads are found, investigate affected user sessions, administrative actions, account setting changes, and unusual client-side redirects around the same timeframe.