CVE-2026-33174: 
Ruby vulnerability analysis and mitigation

CVE-2026-33174 is a Denial of Service (DoS) vulnerability in Rails Active Storage's proxy delivery mode caused by unbounded memory allocation when processing HTTP Range requests. When serving files through ActiveStorage::Blobs::ProxyController, the controller loads the entire requested byte range into memory before sending it, meaning a request with a large or unbounded Range header (e.g., bytes=0-) causes the server to allocate memory proportional to the file size. The vulnerability affects Rails versions prior to 7.2.3.1, 8.0.x prior to 8.0.4.1, and 8.1.x prior to 8.1.2.1. It was disclosed on March 23, 2026, with a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 6.6 (Medium) (GitHub Advisory, Feedly).

The root cause is classified under CWE-789 (Memory Allocation with Excessive Size Value) and CWE-770 (Allocation of Resources Without Limits or Throttling). In the vulnerable code path within ActiveStorage::Streaming#send_blob_byte_range_data, the controller parses the Range header using Rack::Utils.get_byte_ranges and then loads the full byte range into memory without validating its size against any upper bound. An unauthenticated remote attacker can send an HTTP GET request to a proxy-mode Active Storage blob URL with a header such as Range: bytes=0-, causing the server to attempt to load the entire file into memory. The fix introduces a ranges_valid? method that checks whether the total size of all requested ranges exceeds a configurable ActiveStorage.streaming_chunk_max_size (defaulting to 100 MB), returning HTTP 416 (Range Not Satisfiable) if exceeded (GitHub Commit, GitHub Advisory).

Successful exploitation results in memory exhaustion on the Rails application server, potentially causing service degradation or a complete crash, impacting availability with no effect on confidentiality or integrity. Because the attack requires no authentication and has low complexity, any internet-facing Rails application using Active Storage in proxy delivery mode is at risk. Repeated requests targeting large files could sustain a DoS condition, disrupting all users of the affected application (Feedly, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The vulnerability has an EPSS score of approximately 0.016% (0.000160), indicating a low probability of exploitation in the near term. No threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack is network-accessible, requires no privileges or user interaction, and has low complexity, making it straightforward to attempt if an attacker identifies a vulnerable target using Active Storage in proxy mode.

1. Reconnaissance: Identify Rails applications using Active Storage in proxy delivery mode (look for routes serving /rails/active_storage/blobs/proxy/ or similar endpoints) via web crawling, Shodan, or application fingerprinting.
2. Identify a valid blob URL: Access the target application and locate a publicly accessible or authenticated file attachment served via the Active Storage proxy controller (e.g., a profile image, document, or media file).
3. Craft a malicious Range request: Send an HTTP GET request to the blob proxy URL with an unbounded Range header:

   GET /rails/active_storage/blobs/proxy/<signed_id>/<filename> HTTP/1.1
   Host: target.example.com
   Range: bytes=0-

4. Trigger memory exhaustion: The server attempts to load the entire file into memory before responding. For large files, this allocates significant memory per request.
5. Amplify the attack: Send multiple concurrent requests targeting large files to exhaust available server memory, causing the Rails process to crash or become unresponsive, resulting in a DoS condition (GitHub Advisory, GitHub Commit).

• Network: High volume of HTTP GET requests to Active Storage proxy endpoints (e.g., /rails/active_storage/blobs/proxy/) from one or more source IPs, particularly with Range: bytes=0- or other large/unbounded Range headers.
• Logs: Rails application logs showing repeated requests to blob proxy URLs with Range headers; HTTP 416 responses after patching (indicating blocked oversized range requests); sudden spikes in memory usage correlated with specific request patterns in web server access logs.
• Process: Rails worker processes consuming abnormally high memory (approaching system limits); OOM (Out of Memory) killer events in system logs (/var/log/syslog or dmesg) terminating Rails processes; application performance monitoring alerts for memory exhaustion.

Upgrade Rails (and the activestorage gem) to the patched versions: 7.2.3.1, 8.0.4.1, or 8.1.2.1 depending on the branch in use (Rails Release, GitHub Advisory). The patch introduces a configurable ActiveStorage.streaming_chunk_max_size (default: 100 MB) that rejects Range requests exceeding this limit with HTTP 416. As an additional hardening measure, operators can lower this limit via config.active_storage.streaming_chunk_max_size in their Rails configuration. Applications not using Active Storage in proxy delivery mode (i.e., using redirect mode instead) are not affected and do not require immediate action. IBM has also released patches for affected products including Aspera Faspex, CloudPak for AIOps, and License Metric Tool (IBM Advisory).

The Rails team published a security advisory and released patched versions on March 23, 2026, crediting HackerOne researcher "pirikara" for responsible disclosure (GitHub Advisory). The official Rails blog announced the releases of versions 7.2.3.1, 8.0.4.1, and 8.1.2.1 addressing this and several other CVEs simultaneously (Rails Blog). Red Hat tracked the vulnerability and IBM issued advisories for downstream products incorporating the affected gem. Community reaction was measured given the Low/Medium severity rating and lack of known exploitation.