Back to blog
CVERailsRCEtechnique

Rails Active Storage: a critical flaw with arbitrary file read and RCE potential

Published on 2026-08-016 min readCleanIssue

> In short: A critical vulnerability in the Ruby on Rails Active Storage framework allows an unauthenticated attacker to read arbitrary files from the server's filesystem, with potential escalation to remote code execution. Active Storage is the default file-upload handling in Rails applications. A patched version is available.

Why this matters to you

If your SaaS product is built on Ruby on Rails — and a significant share of French startups and SaaS vendors use Rails — Active Storage is almost certainly in your stack. It handles file uploads (avatars, documents, attachments) by default. This flaw doesn't require authentication, which means any internet-facing Rails app with Active Storage enabled is potentially vulnerable.

The blog already covers CVE-2019-5418 (Rails Action View file read) — this is the same class of vulnerability (arbitrary file read) on a different Rails component, and the escalation path to RCE makes it worse.

The flaw class

The vulnerability allows an attacker to read arbitrary files from the server. In Rails, the most sensitive targets are:

  • config/database.yml — database credentials.
  • config/master.key or config/credentials.yml.enc — the Rails encryption key, which decrypts stored secrets (API keys, third-party tokens).
  • /etc/passwd, environment variables — system information for further exploitation.
  • From file read to RCE: if the attacker can read the Rails master key, they can decrypt credentials.yml.enc and extract every secret stored there — including API keys for cloud providers, third-party services, and internal APIs. With those credentials, the attacker pivots to RCE on dependent infrastructure (deploy a container with stolen cloud credentials, access an internal API with admin tokens).

    What to do

  • Patch Active Storage to the fixed version immediately. Check your Rails version and the corresponding security release.
  • Audit file-access logs for anomalous reads — the vulnerability produces real filesystem reads, which may appear in audit logs if file integrity monitoring is enabled.
  • Rotate the Rails master key if you suspect exposure. This is the nuclear option — it invalidates all encrypted credentials — but it's the correct response if the key was readable during the vulnerability window.
  • Move secrets out of `credentials.yml.enc` into a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler). The master key is a single point of failure; a secrets manager scopes access per-service and rotates automatically.
  • The Rails pattern

    Rails has a history of file-read vulnerabilities (CVE-2019-5418 was Action View, this is Active Storage). The framework's convention-over-configuration approach makes it easy to ship features quickly but also creates predictable file locations that attackers target. For a SaaS vendor on Rails: keep your framework version current, treat the master key as your most sensitive credential, and assume any file-read vulnerability is effectively a full secret compromise.

    Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.

    Sources

    Written by CleanIssue
    Reviewed on 2026-08-01

    Related services

    If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.

    Need an external review of your HR SaaS?

    Share your product, stack, and client context. We will come back with the right review scope.

    Discuss your audit