CVE-2023-28120

What it actually does

This flaw affects Rails ActiveSupport::SafeBuffer handling when the bytesplice method is used with untrusted input. SafeBuffer is intended to track strings that are considered safe for HTML rendering, but vulnerable behavior can allow attacker-controlled content inserted through bytesplice to retain or inherit HTML-safe treatment instead of being escaped. If application code uses bytesplice on a SafeBuffer with request-controlled data and later renders the result into an HTML response, an attacker may inject executable HTML or JavaScript, resulting in cross-site scripting. The impact is primarily integrity of rendered web content and browser-side execution in the context of the affected application; it does not directly provide server-side code execution.

Why it matters to the business

Successful exploitation can let an attacker alter what users see in a web application, run malicious script in users' browsers, steal session-related data that is accessible to JavaScript, perform actions as the user, or redirect users to phishing or malware pages. The risk depends heavily on whether the Rails application actually calls bytesplice on SafeBuffer objects with user-supplied input. Although the CVSS score is moderate, Rails is widely used and vulnerable coding patterns may exist in custom application code, plugins, or downstream components, so organizations should treat internet-facing applications and authenticated portals as higher priority. This issue is not listed in CISA KEV and has low EPSS, with no known exploit maturity provided, so it is less urgent than actively exploited vulnerabilities but still important to remediate during normal application security maintenance.

How an attack unfolds

An attacker first identifies a Rails application path where user-controlled input is incorporated into an HTML-safe string. The vulnerable pattern requires application or library code to call bytesplice on an ActiveSupport::SafeBuffer using attacker-controlled data, then render the resulting buffer into an HTML response. The attacker submits a crafted value containing HTML or JavaScript, such as an event-handler attribute, script tag, SVG payload, or JavaScript URL, through a query parameter, form field, API field, profile value, message body, or similar input source. Because the vulnerable SafeBuffer behavior can preserve unsafe content as safe, Rails escaping defenses may be bypassed for that inserted content. When another user or the attacker views the affected page, the browser interprets the injected content as markup or script. The attacker can then perform browser-context actions such as stealing accessible tokens, modifying page content, initiating application requests as the victim, or redirecting the victim to an attacker-controlled site.

How to fix it

Upgrade Rails/ActiveSupport to a release that includes the upstream fix for this issue, or apply the Rails commit 3cf23c3f891e2e81c977ea4ab83b62bc2a444b70 if maintaining a source-based or pinned Git dependency. Avoid relying on manual backports unless they are tested against the affected ActiveSupport SafeBuffer behavior. Review custom code, engines, gems, and view helpers for uses of bytesplice on SafeBuffer or strings marked html_safe, especially where values originate from request parameters, persisted user content, headers, or external integrations. Do not pass untrusted input into SafeBuffer mutation methods unless it is explicitly escaped first. Prefer Rails escaping helpers, sanitized rendering patterns, and safe templating APIs. Remove unnecessary html_safe calls, avoid constructing HTML through string mutation, and use tag helpers or component frameworks that escape by default. As a defense-in-depth mitigation, enforce a strong Content Security Policy that restricts inline scripts and untrusted script sources, while recognizing CSP does not replace patching.

How to confirm the fix worked

Confirm the deployed Rails/ActiveSupport version or Git revision includes commit 3cf23c3f891e2e81c977ea4ab83b62bc2a444b70 or a fixed upstream release. Use software composition analysis, dependency lockfile review, container image scanning, and runtime package inspection to verify all deployed application instances use the fixed code. Search source code for bytesplice, ActiveSupport::SafeBuffer, html_safe, safe_concat, raw, and custom HTML-building helpers, then verify untrusted input is escaped before insertion. Add regression tests that pass payloads such as <script>alert(1)</script>, <img src=x onerror=alert(1)>, SVG event payloads, and javascript: URLs through any suspected code path and assert they are escaped or removed in rendered output. In staging or a controlled test environment, reproduce affected rendering behavior before and after the patch to confirm payloads no longer execute. Validate that CSP, secure cookie settings, and output-encoding controls remain enabled after remediation.

Typical attack path

1. Find or fuzz Rails application functionality that reflects, stores, or renders user-controllable input in HTML responses.
2. Identify a code path where the application or a dependency uses ActiveSupport::SafeBuffer#bytesplice with that untrusted input.
3. Submit a payload containing HTML or JavaScript designed to survive escaping and execute in a browser context.
4. Cause the vulnerable page or component to render the manipulated SafeBuffer output.
5. Execute attacker-controlled script in the victim user's browser under the affected application's origin.
6. Use the browser context to steal accessible data, perform unauthorized in-app actions, modify displayed content, or redirect the user.

How to detect it

To determine whether this was already exploited, combine source-code exposure analysis with web telemetry review. First identify routes, templates, helpers, or dependencies that use bytesplice with SafeBuffer or html_safe content; exploitation is only plausible where attacker-controlled input reaches those code paths and is rendered in HTML. Review web server, application, WAF, CDN, and reverse-proxy logs for requests to those endpoints containing common XSS payloads, encoded script tags, event-handler attributes, SVG payloads, javascript: URLs, or unusual HTML markup in parameters, form fields, JSON bodies, or persisted content updates. Examine application records that store user-generated content rendered in vulnerable views for embedded script, event handlers, iframe/object/embed tags, data URLs, or obfuscated JavaScript. Review browser-side security telemetry, CSP violation reports, WAF alerts, and EDR/network events for connections from user browsers to unfamiliar domains immediately after visits to affected pages. Look for spikes in suspicious requests, repeated probing of the same parameters, or payloads that are later viewed by privileged users. Because XSS often leaves no server compromise artifact, absence of server-side malware or new processes does not rule out browser-side exploitation.

• bytesplice
• ActiveSupport::SafeBuffer
• html_safe
• safe_concat
• raw(
• <script
• </script>
• %3Cscript
• %3C%2Fscript
• javascript:
• %6A%61%76%61%73%63%72%69%70%74%3A
• onerror=
• onload=
• onclick=
• onmouseover=
• <img src=x onerror=
• %3Cimg%20src%3Dx%20onerror%3D
• <svg onload=
• %3Csvg%20onload%3D
• <iframe
• %3Ciframe
• document.cookie
• localStorage
• sessionStorage
• eval(
• atob(
• String.fromCharCode

What your security team should do

• Inventory Rails applications and services that depend on ActiveSupport, including applications using Rails from Git rather than a packaged gem release.
• Prioritize internet-facing Rails applications, administrative portals, customer-facing workflows, and applications that render user-generated content.
• Upgrade or patch Rails/ActiveSupport to a fixed release or to a revision containing commit 3cf23c3f891e2e81c977ea4ab83b62bc2a444b70.
• Search application and dependency code for ActiveSupport::SafeBuffer#bytesplice and assess whether untrusted input can reach it.
• Remove unsafe html_safe/raw usage and replace string-built HTML with escaping helpers or structured tag/component APIs.
• Deploy or tighten Content Security Policy to reduce the impact of any residual XSS paths.
• Add automated tests for XSS payloads around affected helpers, templates, and rendering paths.
• Review logs and telemetry for historical XSS probing against fields or routes associated with rendered user input.
• Monitor dependency advisories for Rails/ActiveSupport because downstream packages may release their own fixed versions or guidance.