Rails Patches Critical Active Storage Flaw with RCE Potential (CVE-2026-66066)

The Ruby on Rails security team has released emergency patches for CVE-2026-66066, a critical vulnerability in Active Storage that allows attackers to read arbitrary files from the server through crafted image uploads. With a CVSS score of 9.5, the flaw — nicknamed KindaRails2Shell by Rapid7 researchers — carries real remote code execution potential that the Rails team confirms it cannot rule out.

What's the Problem?

Active Storage uses libvips as the default image processor since load_defaults 7.0 in Rails 7.x and 8.x. The bug (classified as CWE-1188, insecure default initialization) arises because Active Storage passes untrusted uploaded files to libvips without disabling its "unfuzzed" image loaders — loaders designed for trusted input that have the ability to read arbitrary file types and paths.

When an application accepts image uploads from untrusted users and triggers variant generation (thumbnail creation, format conversion, resizing), a crafted file can cause libvips to read arbitrary files on the server — including the process environment.

That environment typically contains:

• secret_key_base and the Rails master key
• Database connection strings and passwords
• AWS, GCS, or Azure storage credentials
• Third-party API tokens (payment processors, email providers, etc.)

From File Read to Full RCE

The jump from arbitrary file read to remote code execution is enabled by Rails' own deserialization framework. Once an attacker obtains secret_key_base, they can forge signed and encrypted Rails cookies — and Rails will deserialize the payload on the next request. Deserialization gadget chains in the Ruby ecosystem are well-documented, and a working RCE mechanism from this starting point is a known attack pattern.

The Rails security team stated it is "not aware of exploitation attempts before or after disclosure, but the absence of known attacks should not be interpreted as evidence that exposed applications are safe." A third-party proof-of-concept appeared shortly after coordinated disclosure, and a Metasploit module was added to the project's Kanban board on July 30, 2026. Full attack-chain details are being withheld until August 28, 2026 to allow time for patching.

Affected Versions

Rails 7.0 and 7.1 are end-of-life and will not receive backported fixes. Applications on those branches must either upgrade the major version or implement a workaround.

Discovery

The vulnerability was independently discovered and reported by two research teams:

• Ethiack: André Baptista (0xacb), Bruno Mendes (S3np41k1r1t0), and Rafael Castilho
• GMO Flatt Security: RyotaK (reported a few days after Ethiack's initial report)

Workarounds

If an immediate upgrade is not possible:

1. libvips 8.13+: Set the VIPS_BLOCK_UNTRUSTED=1 environment variable in your application's process environment.
2. ruby-vips 2.2.1+: Add a Rails initializer calling Vips.block_untrusted(true).
3. Regardless of patch status: Rotate all potentially exposed secrets — secret_key_base, database credentials, storage keys, and API tokens.

What to Do Right Now

For any Rails 7.x or 8.x application that accepts file or image uploads:

1. Upgrade Rails and Active Storage to the patched version for your branch.
2. Verify your libvips version is 8.13 or later — upgrading Rails alone is insufficient if the system libvips is older.
3. Rotate secrets as a precaution, even before you can confirm exposure.
4. Audit your upload handling — applications that only accept uploads from authenticated users have a significantly reduced attack surface, but the vulnerability still exists.

The GitHub Security Advisory is GHSA-xr9x-r78c-5hrm. Patches are available via gem update rails or by pinning to the fixed versions in your Gemfile.