ACTIVESTORAGE · GHSA-4v2w-w6g6-f8f8 · Package
FIX → 8.1.4.1 +1
When Active Storage streams a file through its proxy routes and the storage service fails after the response has started, the server thread blocks until restart. Repeated failed downloads can exhaust server threads and cause a denial of service.
first public Nov 4, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that store Active Storage files on a service that streams downloads in several requests, such as Amazon S3, an S3-compatible service or Google Cloud Storage, and that use Active Storage's default proxy routes. The proxy routes are drawn whether or not proxy mode is the default, so the exposure does not depend on that setting. Apps that serve files only through redirects or do not use these storage services can skip it.
Not affected if no-proxy-routes, non-streaming-storage
Who cares activestorage, google-cloud-storage, rails, ruby, s3
activestorageUpgrade to 8.1.4.1 +1
When Active Storage serves a file through its proxy controllers, ActiveStorage::Streaming#send_blob_stream handles an error from the storage service by calling head to send a 404 or 500 response. If the error occurs after the first chunk has been written, the response is already committed, and head replaces the response body while the server is still reading the original ActionController::Live buffer. That buffer is never closed, so the server thread handling the request blocks until the process restarts. Repeated failed downloads could exhaust the server's threads, possibly resulting in a DoS vulnerability.
Applications are affected when they store files on a service that streams a download in several requests, such as Amazon S3, an S3-compatible service or Google Cloud Storage, and draw Active Storage's default routes. The proxy routes are drawn whether or not proxy mode is the default for the application. A file deleted while it is being served, or any other storage error partway through a download, triggers the condition.
A storage error raised before the response is committed still produces a 404 or 500 response. After the fix, a storage error raised after the response is committed is re-raised instead, so the server closes the streamed response and releases the thread; the client receives a truncated body, and the exception reaches the application's error reporting.
The fixed releases are available at the normal locations.
Patches for those who cannot upgrade at once:
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
8.1.4.1 for the 8.1 line8.0.5.2 for the 8.0 lineThis issue was found by the Anthropic OSS Scanner (ANT-2026-FMPUMYTB).