TL;DR: A critical Rails Active Storage RCE flaw, CVE-2026-66066 (CVSS 9.5), lets an unauthenticated attacker read server files and potentially run code through crafted image uploads. A public Metasploit module now automates the full exploit chain. Patches landed in Rails 7.2.3.2, 8.0.5.1, and 8.1.3.1.
- CVE: CVE-2026-66066
- CVSS: 9.5 (Critical · CVSSv4)
- Product: activestorage (rubygems)
- Affected: < 7.2.3.2, >= 8.0.0.beta1, < 8.0.5.1, >= 8.1.0.beta1, < 8.1.3.1
- Impact: Action Pack: Possible arbitrary file read and remote code execution in Active Storage variant processing
- Status: No confirmed exploitation yet
- Patched in: 7.2.3.2, 8.0.5.1, 8.1.3.1
- EPSS: 1.7% (30-day)
- Action: Update to 7.2.3.2, 8.0.5.1, 8.1.3.1 now
Why it matters
Rails ships libvips as the default image processor since version 7.0. Any app that accepts image uploads from untrusted users is a target. Exposed secrets like secret_key_base, database passwords, and cloud tokens can hand an attacker full control. The Ethiack research team, who discovered the flaw alongside GMO Flatt Security, dubbed the attack chain KindaRails2Shell.
How the attack works
Active Storage did not block libvips operations marked unsafe for untrusted content. An attacker uploads a crafted file, then triggers variant processing. The unsafe loader reads arbitrary files from the server, including /proc/self/environ. Those environment variables often hold signing secrets.
Once the attacker recovers secret_key_base, they forge a signed Active Storage variation key. That key invokes command execution through the ImageProcessing pipeline. The result is Rails Active Storage RCE without any login.
Public exploit code
Security researcher jburgess-r7 submitted a Metasploit module for CVE-2026-66066. The module chains file read, secret recovery, and code execution into a single workflow. It supports multiple key-generator and message-format combinations. This public proof-of-concept raises the urgency to patch.
Affected versions
The flaw hits Active Storage before 7.2.3.2, versions 8.0.0 through 8.0.5.0, and 8.1.0 through 8.1.3.0. Rails 6.x is also at risk when the vips processor was enabled manually. The fix further requires libvips 8.13 or newer.
Patch and mitigation
Upgrade to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 as described in the official GitHub security advisory. Confirm that libvips is 8.13 or later, since older versions cannot disable the unsafe operations. Then rotate every secret the app process can read. Upgrading alone does not undo prior exposure. As a stopgap, set the VIPS_BLOCK_UNTRUSTED environment variable on libvips 8.13 and above.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.