If you use Ruby on Rails, you’ve likely relied on Active Storage for managing file uploads and blobs. But in early 2024, a critical vulnerability—CVE-2024-26144—was discovered that could secretly leak your users’ session data. Let’s walk through what happened, why it’s risky, how to detect if you’re affected, and how to patch your app—all in direct, actionable language.

What is CVE-2024-26144?

CVE-2024-26144 is a security bug found in Rails (from version 5.2.) affecting how Active Storage serves files (called "blobs"). By default, when Active Storage sends files to users, it also sends the user's Set-Cookie header. Even worse, it slaps a Cache-Control: public header on the response. This means:

> Some caches, CDNs, or proxies in front of your app could save a response with a real user's session cookie attached.

If another user requests the same file, the cache might replay the first user's session cookie. User A’s session can be leaked to User B.

User Alice asks for a photo stored via Active Storage.

2. Rails serves the file. It attaches Alice’s real session cookie in a Set-Cookie header (because Alice is logged in).

Here’s what the HTTP response from an affected Rails version might look like

HTTP/1.1 200 OK
Set-Cookie: _yourapp_session=abc123xyz; path=/; HttpOnly
Content-Type: image/jpeg
Cache-Control: public
Content-Length: 39102

<IMAGE DATA>

The Set-Cookie header (with Alice's session) is accidentally signed up for delivery to anyone who asks! Yikes.

Why Does This Happen in Rails?

The culprit is how Active Storage serves files using the controller stack, which attaches all headers—including session cookies—to every response. Since cache headers mistakenly allow caching, any *shared* proxy can cache the entire response—including the private cookie.

It only happens for controllers serving blobs using Active Storage’s built-in routes, not custom (non-Active Storage) file delivery.

Applications using Rails 5.2. or newer and Active Storage

- Sites serving files directly via /rails/active_storage/blobs/...
- Deployments behind caching proxies, CDNs, or reverse proxies (like Varnish, Cloudflare, Fastly, etc.)

Run:

# For Rails 7
bundle update rails

# Or target a safe minor in Gemfile:
gem 'rails', '~> 7..8.1'

Patch Example (Simplified from GitHub PR)

# Somewhere in ActiveStorage controller code
response.set_header('Cache-Control', 'private')

Or navigation of session/cookie handling that strips sessions from blob responses.

Check response headers in your browser (network tab in DevTools)

3. If you see a Set-Cookie header AND Cache-Control: public when accessing a blob URL, you're at risk.

The attacker’s browser uses the victim’s session—maybe even logging them in as the victim

This allows session hijacking without the victim clicking on unusual links or falling for phishing—they just request a normal file!

Additional References

- Rails Security Advisory 2024-02-15
- Active Storage GitHub Issue PR
- NIST CVE-2024-26144 Entry

Example workaround (config/initializers/active_storage_fix.rb)

Rails.application.config.after_initialize do
  ActiveStorage::BlobsController.class_eval do
    after_action :strip_set_cookie, only: [:show]

    def strip_set_cookie
      response.delete_header('Set-Cookie')
      response.set_header('Cache-Control', 'private')
    end
  end
end

Bottom Line

Even if you don’t use a CDN or reverse proxy now, it’s best to patch. You never know when your deployment changes! Update Rails if you use Active Storage. Without this patch, a user’s private session could be exposed to anyone who downloads the same file—even across different accounts.

Stay secure, update often, and check headers.

Want to learn more about Rails security updates?
- Rails Security Guides
- OWASP Cheat Sheet: File Upload Security

Timeline

Published on: 02/27/2024 16:15:46 UTC
Last modified on: 02/28/2024 14:07:00 UTC