CVE-2026-33174

What it actually does

This vulnerability affects Ruby on Rails applications using Active Storage proxy delivery mode. When a client requests a file with a large or open-ended HTTP Range header, such as `Range: bytes=0-`, the vulnerable proxy controller reads the entire requested byte range into application memory before streaming the response. For large stored objects, a single request can cause memory allocation proportional to file size; repeated or concurrent requests can exhaust worker memory, trigger garbage-collection pressure, kill application processes, or make the service unavailable. The issue is remotely reachable over HTTP, requires low attack complexity, and does not require user interaction.

Why it matters to the business

Successful exploitation can make Rails applications unavailable or unstable, especially where Active Storage is used to serve large files through the application instead of directly from object storage or a CDN. Operational effects can include elevated memory usage, crashed web workers, degraded response times, failed uploads/downloads, autoscaling events, and service outages. Although EPSS is currently low at 0.0061, the flaw is network-accessible, has a high availability impact, and has been public for 138 days, so exposed applications should be patched during normal vulnerability remediation cycles or sooner for internet-facing file delivery endpoints.

How an attack unfolds

An attacker identifies a Rails application endpoint that serves Active Storage blobs or representations through proxy mode. The attacker then requests a large file using an HTTP Range header that asks for a very large or unbounded range, for example `bytes=0-`. In vulnerable Rails versions, the proxy controller materializes the requested range in memory before returning the response. If the referenced object is large enough, the request causes significant memory growth in the Rails process. By repeating the request, targeting multiple large files, or sending concurrent requests, the attacker can exhaust available memory, force worker restarts, degrade application throughput, or cause a denial of service. There is no current indication that this vulnerability is listed in CISA KEV, used in ransomware campaigns, or associated with named threat actors, but exploitation is straightforward once a suitable proxied Active Storage URL is available.

How to fix it

Upgrade Rails to a patched version: 8.1.2.1 or later, 8.0.4.1 or later, or 7.2.3.1 or later, depending on the application’s Rails branch. If immediate upgrade is not possible, reduce exposure by disabling Active Storage proxy delivery where feasible, switching file delivery to redirect mode, serving large files directly from object storage or a CDN, enforcing request-size and Range-header limits at the reverse proxy or load balancer, rate-limiting repeated requests to Active Storage endpoints, and restricting access to large blob URLs. Ensure application servers have memory limits and worker restart policies, but treat these as containment controls rather than a fix.

How to confirm the fix worked

Confirm the application is running a patched Rails version by checking the deployed Gemfile.lock, package inventory, container image, or runtime dependency list for Rails versions 8.1.2.1+, 8.0.4.1+, or 7.2.3.1+. Verify whether Active Storage proxy delivery is enabled and whether routes such as `/rails/active_storage/blobs/proxy/` or `/rails/active_storage/representations/proxy/` are reachable. In a non-production test environment, request a large Active Storage object with an open-ended Range header and confirm memory use remains bounded after patching. Also validate that reverse proxies, CDNs, or WAF rules correctly limit abusive Range headers without breaking legitimate partial-content downloads.

Typical attack path

1. Discover a Rails application that exposes Active Storage proxy delivery endpoints.
2. Find or obtain a valid proxied Active Storage blob or representation URL, preferably one referencing a large object.
3. Send an HTTP request with a large or open-ended Range header such as `Range: bytes=0-`.
4. Cause the Rails proxy controller to allocate memory proportional to the requested file range.
5. Repeat the request or run concurrent requests to increase memory pressure.
6. Trigger worker crashes, degraded performance, autoscaling churn, or full application denial of service.

How to detect it

To determine whether exploitation may have occurred, review web server, reverse proxy, CDN, WAF, and Rails application logs for requests to Active Storage proxy endpoints containing open-ended or unusually large Range headers. Focus on paths containing `/rails/active_storage/blobs/proxy/` and `/rails/active_storage/representations/proxy/`, especially where responses are HTTP 206 Partial Content, HTTP 200 with large response sizes, HTTP 500/502/503, or are followed by application worker restarts. Correlate suspicious requests with spikes in process RSS memory, container OOM kills, host memory pressure, increased garbage-collection time, Puma/Unicorn/Passenger worker exits, Kubernetes OOMKilled events, autoscaling events, or load balancer health-check failures. Look for repeated requests from the same IP, user agent, ASN, or unauthenticated session that use `Range: bytes=0-`, very large ending offsets, overlapping ranges, or high concurrency against large blobs. Because exploitation primarily causes availability impact, there may be no persistent file artifact; detection depends mainly on HTTP telemetry and infrastructure health logs.

• Range: bytes=0-
• HTTP_RANGE=bytes=0-
• bytes=0-
• /rails/active_storage/blobs/proxy/
• /rails/active_storage/representations/proxy/
• ActiveStorage::Blobs::ProxyController#show
• ActiveStorage::Representations::ProxyController#show
• status=206
• HTTP 206
• Partial Content
• OOMKilled
• out of memory
• Cannot allocate memory
• worker timeout
• PumaWorkerKiller
• SIGKILL
• killed worker
• ActionController::Live

What your security team should do

• Prioritize patching internet-facing Rails applications that use Active Storage proxy delivery for large files.
• Upgrade Rails to 8.1.2.1+, 8.0.4.1+, or 7.2.3.1+ according to the deployed branch.
• Inventory applications for Active Storage proxy routes and large file-serving behavior.
• Add temporary controls to block or limit open-ended and excessively large Range requests to Active Storage proxy endpoints until patching is complete.
• Monitor application memory, worker restarts, HTTP 206 responses, and spikes in requests with Range headers to Active Storage URLs.
• Review recent logs for signs of repeated `bytes=0-` or unusually large byte-range requests against Active Storage proxy endpoints.
• Prefer CDN or object-storage direct delivery for large files where compatible with application requirements.