CVE-2024-47887

What it actually does

This is a network-reachable denial-of-service flaw in Rails Action Pack / Action Controller HTTP Token authentication. Applications on Rails versions starting at 4.0.0 and before 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1 may spend excessive CPU time parsing a specially crafted HTTP Authorization header when they use HTTP Token authentication helpers such as authenticate_or_request_with_http_token. The issue is a regular expression denial of service condition: the attacker does not need authentication, user interaction, or local access, and successful exploitation primarily affects availability rather than confidentiality or integrity. Rails applications running on Ruby 3.2 or newer are reported as unaffected because Ruby 3.2 includes mitigations relevant to this parsing behavior.

Why it matters to the business

An exposed vulnerable application can be made slow or unavailable by repeated crafted web requests, potentially disrupting login flows, APIs, background integrations, customer-facing services, and internal tools that depend on affected Rails endpoints. The risk is most important for internet-facing Rails applications that use token-based HTTP authentication. Current public risk signals are moderate-to-low: EPSS is low, the vulnerability is not in CISA KEV, it is not known to be used in ransomware campaigns, and no mature public exploit is indicated; however, the flaw has been public for a long time, so affected services should still be upgraded during normal security maintenance or sooner for critical public-facing systems.

How an attack unfolds

An attacker first identifies a Rails application endpoint that accepts HTTP Token authentication, commonly an API or controller action protected by token authentication helpers. The attacker then sends HTTP requests containing an intentionally malformed or pathological Authorization header using the Token authentication scheme. On vulnerable Rails and Ruby combinations, Action Controller attempts to parse the header and can spend an unexpectedly long time processing it. By repeating these requests or sending them concurrently, the attacker can tie up application workers, increase CPU utilization, exhaust request capacity, trigger timeouts, and degrade or interrupt service for legitimate users. The attack does not provide code execution or data access by itself; its value is in service disruption.

How to fix it

Upgrade Rails Action Pack / Rails to a fixed release: 6.1.7.9 or later for the 6.1 branch, 7.0.8.5 or later for the 7.0 branch, 7.1.4.1 or later for the 7.1 branch, or 7.2.1.1 or later for the 7.2 branch. If tracking Rails from source, ensure the fix commit b2fbbfbcaa3d662c68a9ee21ab6cf95eccc2b4ec or an equivalent downstream patch is present. As a workaround where immediate Rails upgrade is not feasible, run the application on Ruby 3.2 or newer, which includes mitigations for this class of issue; Rails 8.0.0.beta1 and later requiring Ruby 3.2 or newer are not affected as described. If Go standard library dependency metadata is relevant in the environment, ensure Go is updated to 1.21.8 or later, but prioritize the Rails Action Pack fix for this vulnerability context. Additional mitigations include applying request timeouts, rate limits, WAF/API-gateway rules for abusive Authorization header patterns, per-IP throttling, and capacity protections for authentication endpoints; these should be treated as compensating controls, not substitutes for patching.

How to confirm the fix worked

Confirm the installed Rails and Action Pack versions from dependency manifests and runtime package inventory, such as Gemfile.lock, bundle list, or application container build output. Validate that actionpack/rails is at or above the fixed branch version, or that the Rails source includes commit b2fbbfbcaa3d662c68a9ee21ab6cf95eccc2b4ec. Confirm the Ruby runtime is 3.2 or newer if relying on the Ruby mitigation. Review application code for use of authenticate_or_request_with_http_token, authenticate_with_http_token, or ActionController::HttpAuthentication::Token to determine exposure. In a controlled non-production test, send malformed Authorization: Token requests and verify they are rejected quickly without elevated CPU, long request duration, worker exhaustion, or timeout errors. Also verify scanners and SCA tools no longer report the vulnerable Rails/Action Pack version.

Typical attack path

1. Identify an internet-facing or otherwise reachable Rails application endpoint that uses HTTP Token authentication.
2. Send test requests with malformed Authorization headers using the Token authentication scheme to determine whether responses are slow or time out.
3. Automate repeated requests with crafted Authorization header values against affected endpoints.
4. Consume application worker threads/processes and CPU through expensive header parsing.
5. Cause elevated latency, 5xx errors, request queueing, health check failures, or temporary application unavailability.

How to detect it

To assess possible prior exploitation, review HTTP access logs from reverse proxies, load balancers, CDN/WAF layers, API gateways, and Rails application logs for abnormal bursts of requests to token-authenticated endpoints where the Authorization header used the Token scheme and requests ended in timeouts, 499/500/502/503/504 responses, or unusually long durations. Correlate these events with APM metrics showing spikes in request duration, application worker saturation, CPU usage, request queue depth, or timeout exceptions. Pay particular attention to unauthenticated remote sources generating many failed or slow requests with oversized, malformed, or repetitive Authorization headers. Rails logs may not record full Authorization headers by default because they are often filtered; in that case, use edge telemetry, WAF logs, request metadata, header length fields, and timing anomalies. Evidence of exploitation is primarily availability-focused and may not leave file, process, registry, or persistence artifacts.

• Authorization: Token
• authenticate_or_request_with_http_token
• authenticate_with_http_token
• ActionController::HttpAuthentication::Token
• Rack::Timeout::RequestTimeoutException
• Net::ReadTimeout
• execution expired
• HTTP 503
• HTTP 504
• upstream timed out
• request timeout
• service unavailable

What your security team should do

• Inventory Rails applications and prioritize internet-facing APIs or services using HTTP Token authentication.
• Upgrade affected Rails branches to 6.1.7.9, 7.0.8.5, 7.1.4.1, 7.2.1.1, or later as applicable.
• If immediate upgrade is blocked, move affected applications to Ruby 3.2 or newer where compatible and apply the relevant Rails patch as soon as possible.
• Add or tune request timeout, rate limiting, and WAF/API-gateway controls for repeated malformed Authorization header requests.
• Search historical web, load balancer, reverse proxy, APM, and application logs for spikes in slow requests, timeouts, and 5xx responses involving Authorization: Token traffic.
• Monitor application worker saturation, CPU spikes, request queue depth, and authentication endpoint latency after disclosure and before patch completion.
• Because this is not currently KEV-listed and EPSS is low, handle as prioritized patching for exposed systems rather than emergency incident response unless telemetry shows active abuse.