CVE-2026-126085: 
Ruby vulnerability analysis and mitigation

CVE-2026-126085 is a file size limit bypass vulnerability in Rails Active Storage's Google Cloud Storage (GCS) direct upload service. ActiveStorage::Service::GCSService#url_for_direct_upload does not bind the declared content length into the signed direct-upload URL, and #headers_for_direct_upload returns no length constraint, allowing uploads of any size regardless of the declared byte_size. This mirrors the weakness previously fixed for the S3 service in CVE-2020-8162. Affected versions are Rails activestorage >= 8.1 and < 8.1.4.1, and all versions < 8.0.5.2. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause is classified under CWE-602 (Client-Side Enforcement of Server-Side Security) and CWE-807 (Reliance on Untrusted Inputs in a Security Decision). The GCS signed URL generated by url_for_direct_upload omits the x-goog-content-length-range header from the signature, meaning Google Cloud Storage imposes no server-side size constraint on the uploaded body. A client can therefore declare a small byte_size when requesting the signed URL, then upload a significantly larger file body using that URL; the resulting blob record retains the declared (smaller) size, effectively deceiving the application's size validation and quota logic. The fix signs the x-goog-content-length-range header with the exact declared byte_size (formatted as N,N) and returns it from headers_for_direct_upload, so GCS rejects any body that does not match (GitHub Advisory, Patch 8.0, Patch 8.1).

Successful exploitation allows an unauthenticated or authenticated direct-upload client to store files in Google Cloud Storage that are arbitrarily larger than the size declared during the upload initiation, bypassing any application-level file size validations and storage quotas. This can lead to unauthorized storage consumption, potential denial-of-service through quota exhaustion, and circumvention of business logic controls that rely on the blob's recorded byte_size. There is no confidentiality impact; the integrity impact is limited to the stored file size metadata being inconsistent with the actual stored object (GitHub Advisory, Feedly).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability was responsibly disclosed by HackerOne researcher f4cts and is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is 0.0, reflecting a very low probability of near-term exploitation (GitHub Advisory, Feedly). Exploitation requires no privileges and no user interaction, but is limited to applications using Active Storage with GCS and direct uploads enabled.

1. Identify target: Locate a Rails application that uses Active Storage with Google Cloud Storage as the backend and exposes a direct-upload endpoint (typically /rails/active_storage/direct_uploads).
2. Initiate a direct upload with a small declared size: Send a POST request to the direct-upload endpoint declaring a small byte_size (e.g., 100 bytes) and a valid checksum for the small payload. The server returns a signed GCS URL and headers.
3. Upload an oversized body: Using the signed URL received in step 2, send a PUT request directly to GCS with a body significantly larger than the declared 100 bytes. Because the signed URL does not include an x-goog-content-length-range constraint, GCS accepts the oversized body.
4. Observe blob metadata mismatch: The Active Storage blob record in the application database retains the declared byte_size of 100 bytes, while the actual object stored in GCS is much larger, bypassing any application-level size validation that relies on the blob's byte_size.
5. Repeat to exhaust quota: Repeat the process to consume storage quota beyond application-enforced limits, potentially causing denial of service or unexpected billing (GitHub Advisory, Patch 8.0).

• Network: Unusually large PUT requests sent directly to storage.googleapis.com buckets associated with the application, where the Content-Length of the PUT body significantly exceeds the byte_size declared in the preceding Rails direct-upload POST request.
• Logs: Rails application logs showing direct-upload blob creation with small byte_size values, followed by GCS object sizes (visible in GCS audit logs or bucket monitoring) that are substantially larger than the declared sizes.
• Storage: GCS bucket objects whose actual size does not match the byte_size stored in the application's active_storage_blobs database table for the corresponding key.
• Application: Unexpected storage quota overages or billing anomalies in the GCS bucket associated with the Rails application (GitHub Advisory).

Upgrade the activestorage gem (part of the rails gem) to version 8.1.4.1 (for Rails 8.1.x) or 8.0.5.2 (for Rails 8.0.x) (Rails 8.0.5.2 Release, Rails 8.1.4.1 Release). For those unable to upgrade immediately, apply the provided patch directly: 8.0 patch or 8.1 patch. Important post-upgrade action: After upgrading, update your GCS bucket's CORS configuration to include x-goog-content-length-range in the responseHeader list; otherwise, browser-based direct uploads will fail (GitHub Advisory).

The vulnerability was responsibly reported through HackerOne by researcher f4cts and was addressed as part of a broader Rails security release that patched multiple vulnerabilities simultaneously. The advisory was published by Rails maintainer Mike Dalessio (flavorjones) on November 4, 2026. No significant independent researcher commentary or broad media coverage specific to this CVE has been identified beyond the official advisory (GitHub Advisory).