CVE-2026-33170: Cross-Site Scripting (XSS) via SafeBuffer State Loss in Rails Active Support

Ruby on Rails utilizes the ActiveSupport::SafeBuffer class to differentiate between raw strings and strings that have been sanitized for HTML output. When the Rails ERB templating engine encounters a SafeBuffer object marked as safe, it bypasses the standard HTML auto-escaping process to prevent double-encoding.

The SafeBuffer class achieves this by overriding standard Ruby String methods to track whether the contents have been altered by untrusted data. When an application renders templates, the framework calls html_safe? on the output variables. If the object returns true, the framework writes the bytes directly to the response stream without applying HTML entity encoding.

This mechanism relies on strict internal state tracking to ensure that any unsafe mutation to a previously safe string properly flags the object as unsafe. Destructive string methods, such as gsub! or sub!, explicitly toggle an internal @html_unsafe boolean to prevent tainted data from rendering without escaping.

CVE-2026-33170 emerges from a failure to maintain this state during string formatting operations. The SafeBuffer#% method creates a new buffer but fails to inherit the @html_unsafe flag from the parent receiver, permitting malicious input to bypass the auto-escaping design.

The vulnerability stems from the implementation of the string formatting operator (%) within the ActiveSupport::SafeBuffer class. When a developer applies formatting to a SafeBuffer instance, the method intercepts the call to properly escape the provided arguments before interpolation.

After escaping the arguments, the method invokes the parent String#% method to perform the actual interpolation. The result of this interpolation is then wrapped in a completely new SafeBuffer instance to maintain the specialized class type.

Because the new instance is generated via self.class.new(), it defaults to its initial safe state. The method logic explicitly overlooks the @html_unsafe instance variable of the original receiver, failing to propagate it to the newly instantiated object. Consequently, an explicitly unsafe buffer yields a purportedly safe buffer after formatting.

The vulnerable implementation of the % operator constructs the return value without assessing the receiver's state. Any existing mutation warning tracked by @html_unsafe is silently discarded during the instantiation of the new buffer. This logic oversight breaks the chain of trust established by the Active Support framework.

The patch introduced in commit 50d732af3b7c8aaf63cbcca0becbc00279b215b7 rectifies this by explicitly checking the receiver's state and propagating it. The developers added a mark_unsafe! protected helper method to allow internal state synchronization.

# Patched activesupport/lib/active_support/core_ext/string/output_safety.rb
def %(args)
  # [..] escaping logic [..]
  new_safe_buffer = self.class.new(super(escaped_args))
  if @html_unsafe
    new_safe_buffer.mark_unsafe!
  end
  new_safe_buffer
end
 
protected
  def mark_unsafe!
    @html_unsafe = true
  end

This modification guarantees that if the original buffer was marked unsafe due to prior destructive mutation, the resulting formatted buffer correctly inherits this restriction. The Rails ERB engine will subsequently enforce HTML escaping on the output, neutralizing any embedded malicious scripts.

Exploiting this vulnerability requires a specific sequence of operations on user-controlled input within a Rails application. An attacker must locate an endpoint where a SafeBuffer object undergoes in-place mutation followed by string formatting.

The initial step involves supplying a malicious payload, such as <script>alert(document.cookie)</script>, to an input field. The application must then apply a destructive method, such as gsub!, to the buffer containing this input. This action correctly flags the buffer as @html_unsafe = true.

The exploitation succeeds when the application subsequently formats this buffer using the % operator. The operation strips the unsafe flag, returning a new buffer that reports html_safe? == true to the templating engine.

When the Rails view layer renders this resulting string, the ERB engine reads the erroneous safe status and skips auto-escaping. The raw JavaScript payload is embedded directly into the HTML document and executed by the victim's browser upon page load.

The successful exploitation of this vulnerability yields Cross-Site Scripting (XSS) within the context of the affected application. Because the ERB auto-escaping is fully bypassed, attackers can inject arbitrary HTML and JavaScript into the responses served to end users.

Code execution in the victim's browser enables comprehensive session hijacking, data exfiltration, and unauthorized actions performed on behalf of the user. This aligns with MITRE ATT&CK techniques T1189 (Drive-by Compromise) and T1185 (Browser Session Hijacking).

Attackers often leverage this class of vulnerability to target administrative users, executing actions with elevated privileges. Successful payload delivery requires bypassing any Web Application Firewall (WAF) rules that might detect the initial input string. Because the mutation happens server-side after ingestion, network-level inspection sees only the raw parameters, not the final rendered payload.

The severity is rated Medium (CVSS 5.3) due to the precise code prerequisites required for exploitation. The vulnerability is not a universal bypass; it strictly requires the sequence of destructive mutation followed by string formatting on a single SafeBuffer object.

The primary remediation for CVE-2026-33170 is upgrading the activesupport gem to a patched version. The Rails core team has released versions 7.2.3.1, 8.0.4.1, and 8.1.2.1 to address this vulnerability across all currently supported release branches.

For applications where immediate upgrading is technically unfeasible, developers should audit their codebases for destructive string operations. Searching for methods ending in an exclamation mark (e.g., gsub!, sub!, insert) called on user-controlled data is necessary to identify vulnerable code paths.

Replacing destructive methods with their non-destructive counterparts (e.g., gsub instead of gsub!) acts as an effective workaround. Non-destructive methods correctly handle SafeBuffer state by returning entirely new, properly sanitized string objects rather than mutating existing buffers in place, preventing the specific state desynchronization required for this attack.