CVE-2026-33168

What it actually does

This is a cross-site scripting issue in Ruby on Rails Action View tag helper attribute handling. In vulnerable versions before 8.1.2.1, 8.0.4.1, and 7.2.3.1, a blank string used as an HTML attribute name can bypass normal attribute escaping and produce malformed HTML. If an application lets users control or supply custom HTML attributes, an attacker can craft an attribute value that browsers reinterpret as a separate attribute, such as an event handler or script-bearing attribute, causing attacker-controlled JavaScript to execute in another user's browser. The issue requires a vulnerable application code path that passes user-influenced attribute names or attributes into Action View tag helpers and a victim who views the rendered page.

Why it matters to the business

Successful exploitation can allow account session abuse, unauthorized actions performed in a victim's browser, phishing overlays, content tampering, or theft of data accessible to the victim through the affected application. The risk is highest for Rails applications that expose custom HTML attributes in user-generated content, page builders, CMS-like features, form builders, theming systems, admin-configurable UI components, or integrations that render user-supplied metadata into HTML. The CVSS indicates low attack complexity but requires a specific application pattern and user interaction; EPSS is currently low at 0.00713, it is not in the CISA KEV catalog, and no exploit maturity is reported, so remediation should be prioritized through normal web application patch cycles unless the application allows untrusted users to define HTML attributes.

How an attack unfolds

An attacker first identifies a Rails application feature that accepts user-controlled HTML attributes or metadata later rendered through Action View tag helpers. They then submit input where the attribute name is blank or becomes blank after processing, while placing a payload in the attribute value that can be parsed by the browser as a new HTML attribute. Because vulnerable Action View versions do not correctly escape this malformed blank-name attribute case, the rendered output can break attribute boundaries. When another user views the affected page, the browser may interpret part of the attacker's value as an executable attribute, such as an event handler, and run the embedded JavaScript in the context of the application. From there, the attacker can attempt to read page-accessible data, perform actions as the victim, alter visible content, or redirect the victim to attacker-controlled pages. There are no named threat actors or known ransomware campaigns associated with this vulnerability in the provided intelligence.

How to fix it

Upgrade Rails Action View 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 Rails through the main rails gem, upgrade the Rails bundle to a release that includes the fixed Action View version. If immediate patching is not possible, mitigate by rejecting blank HTML attribute names, allowlisting permitted attribute names, blocking event-handler attributes such as attributes beginning with "on", blocking script-capable URI schemes such as "javascript:", and avoiding rendering untrusted custom attributes through Action View tag helpers. Treat user-controlled HTML attributes as unsafe input and sanitize both attribute names and values before rendering.

How to confirm the fix worked

Confirm dependency versions with package tooling such as `bundle list actionview`, `bundle info actionview`, `bundle exec rails -v`, `Gemfile.lock`, or software composition analysis results. The effective Action View version should be 8.1.2.1, 8.0.4.1, 7.2.3.1, or a later fixed release on the relevant branch. Review application code for uses of Rails tag helpers that accept dynamic attribute hashes, especially `tag`, `content_tag`, form helpers, component helpers, CMS/page-builder rendering, and helpers that merge user-provided options into HTML attributes. Add regression tests that pass a blank-string attribute name with a suspicious attribute value and verify the rendered HTML does not create an executable attribute. In production validation, confirm no public or authenticated user workflow can persist or reflect arbitrary attribute names without allowlist validation.

Typical attack path

1. Find a Rails application running a vulnerable Action View version before 8.1.2.1, 8.0.4.1, or 7.2.3.1.
2. Identify an application feature that lets users specify custom HTML attributes, UI component attributes, metadata, template options, or page-builder properties.
3. Submit crafted input where the HTML attribute name is blank or normalized to a blank string and the attribute value contains browser-parsable attribute syntax.
4. Cause the application to render that input through vulnerable Action View tag helpers.
5. Induce or wait for a victim user to view the rendered page.
6. Have the victim's browser reinterpret the malformed HTML and execute attacker-controlled JavaScript.
7. Use the script execution to steal page-accessible data, perform actions as the victim, modify content, or redirect the user.

How to detect it

To determine whether exploitation may already have occurred, review HTTP access logs, WAF logs, reverse proxy logs, application request logs, audit logs for content/profile/page updates, and database-backed content change histories for inputs that include blank or malformed HTML attribute names combined with XSS payloads. Focus on endpoints that create or update user-generated content, page builder components, templates, themes, forms, profile fields, widgets, or metadata. Look for suspicious values containing browser event handlers, `javascript:` URLs, encoded spaces or quotes, and attempts to inject new attributes into rendered tags. Correlate suspicious submissions with subsequent page views by other users and with abnormal browser-side activity such as unexpected redirects, CSP violation reports, unusual POST requests from victim sessions, or spikes in blocked WAF/XSS signatures. Since exploitation executes in the browser, server-side evidence may be limited to the original stored or reflected payload and any follow-on actions performed using a victim's authenticated session.

• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• javascript:
• data:text/html
• <script
• </script>
• %3Cscript
• %3C%2Fscript
• alert(
• document.cookie
• localStorage
• sessionStorage
• String.fromCharCode
• eval(
• new Function(
• <img src=x onerror=
• <svg onload=
• autofocus onfocus=
• content_tag(
• ActionView::Helpers::TagHelper
• actionview (8.1.2)
• actionview (8.0.4)
• actionview (7.2.3)

What your security team should do

• Inventory Rails applications and libraries using Action View and identify versions earlier than 8.1.2.1, 8.0.4.1, or 7.2.3.1.
• Prioritize patching applications that allow user-generated HTML attributes, page customization, rich content editing, configurable UI components, or externally supplied metadata rendered into views.
• Upgrade Action View/Rails to the appropriate fixed branch version and redeploy affected applications.
• Search code for dynamic attribute rendering patterns where user-controlled hashes or parameters are passed into `tag`, `content_tag`, component helpers, or form/view helpers.
• Implement allowlist validation for custom HTML attribute names and reject blank names regardless of framework version.
• Add automated tests for blank attribute names and common XSS payloads in any feature that renders user-controlled attributes.
• Review web logs and application audit logs for suspicious attribute-injection attempts, especially payloads containing event-handler attributes, `javascript:` URLs, or encoded script delimiters.
• Because EPSS is low and the issue is not KEV-listed, handle broadly through standard vulnerability management, but escalate if the application exposes public content-authoring or customization features.