In the world of web development, security vulnerabilities are a constant concern, especially in major frameworks like Ruby on Rails. In late 2022, an issue was reported about a potential Cross-Site Scripting (XSS) vulnerability in a Rails template file. This was cataloged as CVE-2022-3704 and tracked as VDB-212319. However, this vulnerability has a twist: it's disputed, and its real-world impact remains unproven.

In this long read, we’ll break down the claim around CVE-2022-3704, explain what went on technically, and clarify why the Rails core team does not consider this a legitimate vulnerability. We’ll provide relevant code, references, and guidance to clear up confusion for developers and infosec professionals alike.

The alleged vulnerability affected the following file in the Rails source code

actionpack/lib/action_dispatch/middleware/templates/routes/_table.html.erb

The claim was that user-controllable input could end up in the rendered output without proper escaping, resulting in a situation where attackers could inject malicious JavaScript (i.e., perform XSS).

A classic XSS vulnerability looks like this (example, not the actual Rails code)

<!-- Vulnerable: directly rendering unescaped user input -->
<td><%= params[:user_input] %></td>

If params[:user_input] contains <script>alert('XSS')</script>, the browser will execute it as code. If this happens anywhere in your Rails view templates, it's a serious security issue.

The Issue

In CVE-2022-3704, the specific claim stems from how routes are displayed when running the rails routes command. This part of Rails is used by developers, in development mode – not in deployed, public-facing web applications.

The template in question (_table.html.erb) outputs route information. The security report alleged that route information _could be influenced by a remote attacker_ and that this might allow XSS through manipulated route names, paths, or defaults.

Here’s an example snippet, similar to the code in question

<% routes.each do |route| %>
  <tr>
    <td><%= route.name %></td>
    <td><%= route.verb %></td>
    <td><%= route.path %></td>
    <td><%= route.defaults %></td>
  </tr>
<% end %>

The concern: if route.name or route.path contains unescaped data, and a malicious value slips through, it could be rendered as active HTML or JavaScript.

Code-level Details

You can view the relevant patch here on GitHub:

- <td><%= route.defaults %></td>
+ <td><%= h(route.defaults) %></td>

The fix was to wrap certain outputs with the h helper, which safely escapes HTML.

Maintainers' Note

When the issue was reported, the Rails team investigated. According to their statement, there is no valid or practical attack vector because:

The rails routes output is primarily accessed by developers, not end-users or administrators.

- Route data such as names and paths are defined statically in the Rails source code (routes.rb), not user-supplied or remotely modifiable.
- Even if an attacker could theoretically influence the route information, it would require direct collaboration with the developer or access to the development environment.

Direct quote from maintainers:  
> “There isn’t a valid attack vector. The issue was wrongly reported as a security vulnerability by a non-member of the Rails team.”

The issue is marked as DISPUTED on the official CVE and vulnerability trackers.

If you tried to exploit CVE-2022-3704 by crafting a route like this in config/routes.rb

Rails.application.routes.draw do
  get "/xss", to: "welcome#index", as: '"><script>alert(1)</script>'
end

And then run rails routes, the output might look odd in the routes table. But this is developer-only output, not rendered as part of any production site.

But… If You Serve rails routes Output on the Web?

If someone created an app that exposes rails routes (the HTML) directly to any web user, and allowed others to *edit routes.rb* via a web interface, that would be an application-level security issue, not a Rails framework bug.

Original References

- Official CVE: CVE-2022-3704
- Patch reference: GitHub be177e4566747b7...
- VulDB entry: VDB-212319
- Dispute discussion (GitHub issue): rails/rails#46047

Even though the practical risk is non-existent for most Rails users

- Apply Updates: If you’re using a version of Rails that predates this patch, update to the latest stable version if possible. It’s always wise to keep frameworks current.
- Don’t Panic: There is no need to urgently review your apps regarding this CVE unless you do something highly unusual with exposing rails routes in production.
- Follow Best Practices: Always escape user-supplied data, and never expose development tools or debug outputs in production environments.

Conclusion

CVE-2022-3704 makes for an interesting case study:  
- *Was there vulnerable code?* Strictly, yes—a developer might see unexpected HTML if they maliciously crafted route names themselves.

*Should you take action?* Only as part of routine upgrades.

Security reporting is an imperfect science. Sometimes, a well-intended report gets flagged as a CVE before the community or maintainers fully agree on its importance. CVE-2022-3704 is just such a case—important to clarify, but not something that should keep you up at night.

Stay secure, keep your dependencies updated, and remember: not all CVEs are created equal.

*For further reading and updates, always refer to the official Rails security page and keep an eye out for real, exploitable vulnerabilities.*

Timeline

Published on: 10/26/2022 20:15:00 UTC
Last modified on: 01/19/2023 23:15:00 UTC