A critical vulnerability in Ruby on Rails Active Storage allows unauthenticated attackers to read arbitrary files and achieve remote code execution through crafted image uploads. Tracked as CVE-2026-66066 with a CVSS 4.0 score of 9.5 CRITICAL, the flaw affects default Rails 7.x and 8.x applications using the libvips image processor.

Vulnerability Details

CVE ID: CVE-2026-66066
CVSS 4.0: 9.5 CRITICAL (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H)
CWE: CWE-1188 (Insecure Default Initialization of Resource)
Component: Active Storage variant processing with libvips
Advisory: GHSA-xr9x-r78c-5hrm
Discovered by: Ethiack (Andre Baptista, Bruno Mendes, Rafael Castilho) and RyotaK (GMO Flatt Security)
Public disclosure: July 29, 2026

The vulnerability earned the name KindaRails2Shell because it provides a Rails-to-shell exploitation chain similar to the recent wp2shell WordPress vulnerability, but with additional configuration requirements.

Impact Assessment

Arbitrary File Read

An unauthenticated attacker can upload a crafted image file that, when processed by Active Storage variants, causes libvips to read arbitrary files accessible to the Rails worker process. This includes:

• Process environment variables — exposing SECRET_KEY_BASE, RAILS_MASTER_KEY, database passwords
• Encrypted credentials — config/credentials.yml.enc decrypted contents
• Active Storage service keys — S3, Google Cloud Storage, Azure credentials
• Third-party API tokens — Payment processors, email services, monitoring tools
• Application source code — Any file readable by the application user

Remote Code Execution

The file read primitive enables RCE through a chained exploit:

1. Attacker reads secret_key_base from process environment
2. Attacker forges a malicious Active Storage variation key using the stolen secret
3. The forged variation exploits CVE-2025-24293 (Active Storage transformation method validation bypass)
4. The Vips transformer invokes instance_eval with attacker-controlled Ruby code

Ethiack confirmed this chain works with a crafted MATLAB/HDF5 v7.3 file — a format libvips supports through its matio loader. The payload masquerades as image/png via client-supplied content_type, and a legitimate variation key is replayed against the malicious blob to trigger processing.

Affected Systems

Rails Versions (Default Configuration Vulnerable)

Rails Version Range	Status	Notes
7.0.0 – 7.2.3.1	Vulnerable by default	load_defaults 7.0 enables Vips
8.0.0 – 8.0.5	Vulnerable by default	Vips remains default processor
8.1.0 – 8.1.3	Vulnerable by default	Vips remains default processor
6.0.0 – 6.1.7.10	Vulnerable only with non-default config	Vips not default in Rails 6

Prerequisites for Exploitation

All three conditions must be met:

1. Uses libvips for Active Storage — config.active_storage.variant_processor = :vips (default since Rails 7.0)
2. Accepts image uploads from untrusted users — Avatars, profile pictures, content uploads, direct uploads
3. libvips build includes exploitable operations — Linked against third-party libraries (matio, others) marked “unfuzzed”

Not Affected

• Applications using MiniMagick (:mini_magick processor)
• Applications not using Active Storage
• Rails 6.x with default configuration (Vips not enabled by default)

Mitigation & Patching

Primary Fix: Upgrade Rails

Upgrade to a patched activestorage version immediately:

Critical dependency: The fix requires libvips >= 8.13. Earlier versions cannot disable unfuzzed operations, and Active Storage will raise a boot-time exception on libvips < 8.13.

Mandatory Secret Rotation

Upgrading closes the vulnerability but does not undo prior exfiltration. Treat every secret readable by the application process as potentially exposed and rotate:

Workarounds (If Immediate Upgrade Impossible)

Option 1: Environment variable (libvips >= 8.13 required)

Option 2: Ruby initializer (ruby-vips >= 2.2.1 required)

Option 3: Remove libvips dependency If your application only uses ruby-vips for image analysis (not Active Storage variants), remove it from the Gemfile:

Detection

Forensic Analysis

Rails provides a forensic toolkit to establish exposure window and search for exploitation evidence:

Indicators of Compromise

Monitor for these patterns in logs:

• Unusual image uploads with content_type mismatches (e.g., image/png but file magic bytes indicate MAT/HDF5)
• Variant generation errors from libvips processing unusual formats
• Unexpected file reads by the Rails worker process (auditd, falco)
• Outbound network connections from variant processing workers (the RCE chain uses curl callbacks)

Network Detection (Suricata)

alert http $EXTERNAL_NET any -> $HOME_NET any ( msg:"CVE-2026-66066 KindaRails2Shell MATLAB/HDF5 Upload Attempt"; flow:established,to_server; http.method; content:"POST"; http.header; content:"Content-Type"; http.header; content:"image/"; file_data; content:"MATLAB 5.0"; offset:0; depth:12; classtype:web-application-attack; sid:202666066; rev:1; metadata:cve_2026_66066; )

YARA Rule

rule CVE_2026_66066_KindaRails2Shell_MATLAB_HDF5 { meta: description = "Detects MATLAB v7.3 / HDF5 files used in KindaRails2Shell exploitation" cve = "CVE-2026-66066" severity = "critical" strings: $matlab_header = "MATLAB 5.0" ascii wide $hdf5_signature = { 89 48 44 46 0D 0A 1A 0A } // HDF5 magic bytes condition: $matlab_header at 0 and $hdf5_signature }

Frequently Asked Questions

Is my Rails 6 application affected?

Only if you explicitly configured config.active_storage.variant_processor = :vips. Rails 6 defaults to MiniMagick, so standard Rails 6 apps are not affected.

Does this affect applications using Active Storage with cloud storage (S3, GCS)?

Yes. The vulnerability is in the variant processing step, which happens regardless of where the original file is stored. Cloud-stored files are downloaded, processed with libvips, and the variant is uploaded back.

Can a WAF protect me?

A WAF might block some exploit payloads (e.g., known MATLAB/HDF5 signatures), but it is not a reliable fix. The attack surface varies by deployment (direct upload vs. proxy, variant generation timing). Treat WAF as a temporary mitigation only.

What if I can't upgrade libvips to 8.13?

You have no workaround other than removing the libvips dependency entirely. Active Storage will refuse to boot on libvips < 8.13 with the patched Rails version, as it cannot secure the environment.

Do I need to rotate secrets if I'm not sure I was exploited?

Yes. The Rails security team advises treating all process-readable secrets as potentially exposed. The cost of rotation is far lower than the risk of retaining a compromised secret_key_base or database password.

Are there any known active exploits in the wild?

As of July 29, 2026, the Rails Security Team stated they are not aware of exploitation before or after disclosure. However, a third-party PoC was published on July 29, and Ethiack published their technical analysis on July 31. Assume attackers can reconstruct the chain quickly.

Key Takeaways

1. CVE-2026-66066 is a 9.5 CRITICAL vulnerability in default Rails 7.x/8.x applications using Active Storage with libvips.
2. Arbitrary file read leads to full secret exposure — secret_key_base, master key, database credentials, cloud keys.
3. RCE is achievable via a chained exploit using CVE-2025-24293 and forged variation keys.
4. Upgrade immediately to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 with libvips >= 8.13.
5. Rotate ALL secrets readable by the application process — upgrading alone is insufficient.
6. Use the forensic toolkit to check for prior exploitation in your object storage and Active Storage records.
7. MiniMagick users are not affected by this specific vector — consider switching if libvips upgrade is blocked.

Conclusion

KindaRails2Shell demonstrates how a trust boundary failure between a framework (Active Storage) and its underlying library (libvips) can cascade into catastrophic impact. The vulnerability exploits libvips’ support for obscure formats (MATLAB/HDF5) that are never intended for web image processing, combined with Active Storage’s failure to disable “unfuzzed” operations.

For Rails teams, the remediation path is clear but demanding: upgrade Rails, upgrade libvips, and rotate every secret. The forensic toolkit provides a way to assess historical exposure, but the safest assumption is that any vulnerable deployment may have been compromised.

If you maintain a Rails application with user-facing image uploads, treat this as a highest-priority incident and begin patching and rotation immediately.

---

Sources:

• NVD CVE-2026-66066
• GitHub Security Advisory GHSA-xr9x-r78c-5hrm
• Ethiack Technical Analysis
• The Hacker News Coverage
• Rails Forensic Toolkit
• GMO Flatt Security Analysis
• OpenWall OSS-Security Disclosure