CVE-2023-22792

What it actually does

This is a denial-of-service weakness in Ruby on Rails, most likely in request-processing logic within Action Dispatch where attacker-controlled HTTP metadata can trigger expensive parsing behavior. A crafted request, commonly involving complex or malformed content negotiation headers such as Accept or related MIME-type values, can cause excessive CPU consumption or request-processing stalls. The flaw does not directly provide code execution, authentication bypass, or data disclosure, but it can reduce application availability when vulnerable Rails code is reachable over HTTP.

Why it matters to the business

Successful exploitation can make Rails-backed web applications slow, unstable, or unavailable, disrupting customer-facing services, APIs, internal portals, and background workflows that depend on those applications. The EPSS score is low and the issue is not listed in CISA KEV, with no mature public exploitation indicated, so broad commodity exploitation is not currently strongly signaled; however, because Rails applications are often internet-facing, even low-complexity denial-of-service conditions should be addressed during normal vulnerability remediation cycles.

How an attack unfolds

An attacker identifies an application running a vulnerable Rails version or commit range and sends specially crafted HTTP requests to routes handled by Rails. The requests do not need to reach a sensitive controller action if the vulnerable parsing occurs early in the request lifecycle. By manipulating HTTP headers or request metadata that Rails parses for MIME/content negotiation, the attacker causes Rails to spend disproportionate CPU time processing a small request. Repeating this across concurrent connections can exhaust application worker capacity, increase latency, trigger timeouts, and cause upstream load balancers or reverse proxies to return 5xx errors. There is no indication from the provided data that this issue is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade Rails to a release or source revision that contains the fix. For source-based deployments of rails/rails, ensure the code includes commit c443466a99f8ed951605fb4993a01de5e41349a4 or a later trusted upstream revision. For gem-based deployments, upgrade the Rails components provided by the vendor or Rails project to versions that include this fix, and rebuild/redeploy application containers or packages so the patched code is actually running. If immediate upgrade is not possible, reduce exposure by placing the application behind a reverse proxy or WAF that limits header size and rejects malformed or excessively complex Accept and Content-Type headers, enforce request-rate limits, cap per-client concurrency, configure application request timeouts, and ensure enough worker isolation exists so expensive requests cannot starve all traffic.

How to confirm the fix worked

Confirm the application dependency inventory shows patched Rails code, not only an updated lockfile. For source deployments, verify the deployed rails/rails revision includes c443466a99f8ed951605fb4993a01de5e41349a4 or a later commit. For packaged deployments, verify the resolved Rails gem versions are vendor-confirmed fixed versions and that running containers, servers, or build artifacts were restarted after upgrade. Perform safe negative testing in a non-production environment by sending malformed or oversized content negotiation headers and confirming requests are rejected quickly or processed without abnormal CPU spikes. Review reverse proxy and application timeout settings to ensure malformed requests are bounded.

Typical attack path

1. Discover a Rails-backed HTTP service through fingerprinting, error behavior, headers, or public application behavior.
2. Send test requests with unusual, malformed, or deeply structured Accept, Content-Type, or similar request headers.
3. Observe whether response latency, worker CPU usage, or application error rates increase disproportionately.
4. Automate repeated crafted requests across one or more connections.
5. Consume Rails application worker threads/processes or CPU resources.
6. Cause degraded service, request timeouts, or application unavailability for legitimate users.

How to detect it

Review web server, reverse proxy, load balancer, WAF, and Rails application logs for periods of elevated latency, CPU saturation, worker exhaustion, or bursts of request timeouts correlated with unusual HTTP request headers. Focus on repeated requests containing malformed, very long, or highly repetitive Accept, Content-Type, or MIME-related header values, especially when they come from a small number of source IPs and produce 400-series parsing errors, 408 timeouts, 429 rate-limit responses, or upstream 502/503/504 errors. In Rails logs, look for ActionDispatch, MIME negotiation, bad request, invalid type, parser, timeout, or request timeout exceptions occurring in bursts. In infrastructure telemetry, correlate application worker CPU spikes with low request volume but high per-request processing time, which is typical of algorithmic complexity denial-of-service rather than normal traffic growth. Because this issue is a DoS condition, durable host artifacts may be limited; evidence is most likely in HTTP access logs, WAF events, APM traces, process CPU history, and application exception logs.

• ActionDispatch::Http::MimeNegotiation
• ActionController::BadRequest
• InvalidType
• Invalid MIME type
• HTTP_ACCEPT
• Accept:
• Content-Type:
• Rack::Timeout
• Rack::Timeout::RequestTimeoutException
• Request timeout
• upstream timed out
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

What your security team should do

• Inventory internet-facing and high-availability applications using Ruby on Rails and prioritize those running unpatched source revisions or older Rails packages.
• Upgrade Rails to a fixed release or to a revision containing c443466a99f8ed951605fb4993a01de5e41349a4, then redeploy all affected application instances.
• Add WAF or reverse-proxy controls for maximum HTTP header size, malformed Accept headers, malformed Content-Type headers, request rate, and per-client concurrency.
• Monitor application CPU saturation, request latency, worker exhaustion, and spikes in 408, 429, 499, 500, 502, 503, and 504 responses.
• Search historical logs for bursts of malformed content negotiation headers or repeated slow requests from the same source networks.
• Treat exploitation likelihood as moderate-to-low based on the provided EPSS, no KEV listing, and no mature exploit signal, but remediate proactively for exposed production services.