CVE-2026-126085

### Impact `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, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the `byte_size` it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service. Applications that store files in Google Cloud Storage and accept direct uploads are affected. ### Details The fixed releases sign an `x-goog-content-length-range` header that matches the blob's declared `byte_size` and return it from `headers_for_direct_upload`, so Cloud Storage rejects an upload body of any other size. Browsers send this header with the direct upload, so a bucket's CORS configuration must list `x-goog-content-length-range` in `responseHeader`, or browser direct uploads fail after the upgrade. The Active Storage CHANGELOG and the CORS example in the Active Storage guide show the change. ### Releases The fixed releases are available at the normal locations. Patches for those who cannot upgrade at once: - 8.1: https://github.com/rails/rails/commit/e19916cea31cbfb0030b165ae853b741f8dd57a7.patch - 8.0: https://github.com/rails/rails/commit/7fe85a72a789eae5ee070ce3ee1dad10a8a5f70c.patch ### Credit This issue was responsibly reported by HackerOne researcher [f4cts](https://hackerone.com/f4cts).