Ruby on Rails has released emergency security updates addressing a critical vulnerability in Active Storage that could allow unauthenticated attackers to read arbitrary files from application servers through crafted image uploads. Tracked as CVE-2026-66066 with a CVSS score of 9.5, the flaw exposes Rails process environment variables and secrets including secret_key_base, database credentials, cloud storage keys, and API tokens — potentially enabling remote code execution and lateral movement.

Vulnerability Details

The Core Issue

The vulnerability exists at the trust boundary between Active Storage and libvips, the high-performance image processing library. Active Storage uses libvips (via the ruby-vips gem) for image analysis and transformation when configured to do so. Starting with Rails 7.0, libvips became the default image processor under load_defaults 7.0.

Libvips supports numerous image format loaders, savers, and operations — some backed by third-party libraries marked as "unfuzzed" or "untrusted" because they are unsafe for hostile input. Active Storage did not block these unsafe operations, allowing a crafted image upload to invoke them and disclose files readable by the Rails worker process.

Attack Vector

An unauthenticated attacker uploads a maliciously crafted image file to any endpoint that accepts Active Storage uploads. The image exploits a vulnerable libvips operation to read arbitrary files from the server filesystem. The Rails Security Team confirmed:

"Generating variants is not a separate requirement. A vulnerable application does not need to expose a dedicated resize or thumbnail operation."

Both the Vips analyzer and transformer passed untrusted attachments to unsafe libvips operations.

What Gets Exposed

A successful attack yields an arbitrary file read primitive. Depending on what the Rails process can read, attackers can extract:

• SECRET_KEY_BASE / secret_key_base — enables signed cookie forgery and potential RCE
• Rails master key and decrypted config/credentials.yml.enc — all application secrets
• Database passwords
• Database credentials — direct database access
• Active Storage service keys — cloud storage (S3, GCS, Azure Blob) takeover
• Third-party API tokens — lateral movement to connected services
• Environment variables — complete process environment

Code execution or lateral movement depends on what credentials are extracted and what those credentials can access.

Affected Versions

Rails Version	Status	Notes
7.0.0 – 7.2.3.1	Affected	Default libvips processor
8.0.0 – 8.0.5	Affected	Default libvips processor
8.1.0 – 8.1.3	Affected	Default libvips processor
6.0.0 – 6.1.7.10	Affected (conditional)	Only when Active Storage explicitly configured to use Vips (not default)
7.1 and earlier	EOL	No backports; must upgrade to supported version

Applications using MiniMagick instead of libvips are not exposed through this specific attack path.

Fixed Versions

Upgrade immediately to one of the following patched releases:

Series	Fixed Version
7.2	7.2.3.2
8.0	8.0.5.1
8.1	8.1.3.1

Rails 6.x is end-of-life and will not receive a backport. Applications on Rails 6.x using Vips must upgrade to Rails 7.2.3.2 or later.

Mitigation

Primary: Upgrade Rails

Upgrade to a patched version immediately. The patch calls Vips.block_untrusted(true) when Active Storage initializes, preventing unsafe libvips operations from processing untrusted input.

Secondary: Environment Variable (libvips 8.13+)

If you cannot upgrade Rails immediately but are running libvips 8.13 or later with ruby-vips 2.2.1 or later, set the environment variable:

Or in Ruby initialization code (before Active Storage loads):

Earlier libvips versions cannot block these operations — you must upgrade libvips or remove it from the application.

Tertiary: Remove libvips

If you cannot upgrade Rails or libvips, remove libvips from the application and configure Active Storage to use MiniMagick instead:

Ensure mini_magick and image_processing gems are in your Gemfile.

Post-Exploitation: Secret Rotation Required

Patching alone is insufficient. If an application was vulnerable and accepted untrusted image uploads, assume all secrets readable by the Rails process may have been extracted. The Rails Security Team explicitly advises rotating:

1. secret_key_base (or SECRET_KEY_BASE environment variable)
2. Rails master key and all decrypted credentials
3. Database credentials
4. Active Storage service keys (S3, Google Cloud, Azure Blob Storage)
5. All third-party API tokens and service credentials

Treat this as a full credential compromise incident.

Proof-of-Concept Status

As of July 29, 2026, 17:30 UTC, neither research team (Ethiack or GMO Flatt Security) had published a proof-of-concept. A third-party GitHub repository published afterward claims to reproduce the full arbitrary-file-read-to-RCE chain in a loopback-only Docker lab using Rails 8.1.3, with Rails 8.1.3.1 as the patched control. The exploit uses a crafted MATLAB/HDF5 upload to read the Rails process environment, recover SECRET_KEY_BASE, sign an embedded Marshal payload, and trigger an out-of-band curl callback.

The Hacker News has not independently validated the PoC. The researchers have not disclosed the malicious format, file-read construction, or RCE chain. Rails stated further technical details will be released no later than August 28, 2026.

Technical Root Cause

The vulnerability stems from a design gap: Active Storage assumed libvips operations were safe for untrusted input. However, libvips explicitly documents that some operations are backed by third-party code marked "unfuzzed" or "untrusted" — unsafe for hostile files. The public patch shows both the Vips analyzer and transformer passed untrusted attachments to these unsafe operations without validation.

The fix is a single line in the Active Storage Vips integration:

This leverages a libvips 8.13 feature that disables all operations marked as untrusted.

Detection Guidance

Application-Level Indicators

Monitor for:

• Image uploads with unusual MIME types or file signatures (e.g., MATLAB/HDF5, TIFF with unusual tags)
• Active Storage analyzer/transformer errors mentioning libvips operations
• Unexpected file read patterns in application logs

Infrastructure-Level Indicators

• Unusual outbound network connections from Rails workers (callback attempts)
• Unexpected processes spawned by the Rails application user
• Access to sensitive files (/proc/self/environ, credential files) by the Rails process

CISA KEV Status

As of July 30, 2026, CVE-2026-66066 was not listed in CISA's Known Exploited Vulnerabilities catalog. The Rails Security Team and The Hacker News are not aware of exploitation or attempted exploitation before or after disclosure.

Affected Application Profile

A deployment is only vulnerable if all of the following are true:

1. Rails version in affected ranges above
2. Active Storage is configured to use libvips (default in Rails 7.0+)
3. Application accepts image uploads from untrusted users
4. libvips build includes an exploitable operation (most standard builds do)

No reliable count of vulnerable applications exists. Rails has no telemetry on how many applications use Active Storage with Vips and accept untrusted uploads. The 9.5 CVSS score reflects severity under CVSS, not prevalence of exposure.

Frequently Asked Questions

Does this affect Rails applications using Active Storage with MiniMagick?

No. Applications using MiniMagick as the variant processor are not exposed through this specific attack path. The vulnerability is in the libvips integration only.

Is Rails 7.1 affected?

Rails 7.1 is end-of-life and will not receive a backport. If you are on Rails 7.1 with Active Storage using Vips, you must upgrade to Rails 7.2.3.2 or later.

Can I just disable Active Storage variants?

Disabling variants does not mitigate the vulnerability. The Rails Security Team confirmed: "Generating variants is not a separate requirement." The Vips analyzer runs on upload and is sufficient for exploitation.

What if I don't accept image uploads?

If your application does not accept any file uploads through Active Storage, you are not exposed. However, many applications accept uploads indirectly (user avatars, document attachments, rich text content).

How do I check which image processor my app uses?

Check your Gemfile for ruby-vips and image_processing. Also check config/initializers/active_storage.rb or config/application.rb for config.active_storage.variant_processor. The default in Rails 7.0+ is :vips.

Will there be more technical details released?

Yes. Rails stated further technical details will be released no later than August 28, 2026. The researchers (Ethiack and GMO Flatt Security) have not yet published their full write-ups.

Key Takeaways

1. CVE-2026-66066: CVSS 9.5 — Critical Active Storage vulnerability via libvips
2. Unauthenticated arbitrary file read — leads to credential theft and potential RCE
3. Affects Rails 7.0–7.2.3.1, 8.0–8.0.5, 8.1–8.1.3 (and Rails 6.x with explicit Vips)
4. Fixed in 7.2.3.2, 8.0.5.1, 8.1.3.1 — upgrade immediately
5. No exploitation observed as of July 30, 2026 — but PoC exists
6. Rotate ALL secrets after patching — assume compromise
7. Mitigation without upgrade: VIPS_BLOCK_UNTRUSTED=true (requires libvips 8.13+)
8. MiniMagick users not affected — consider switching as defense-in-depth

Conclusion

CVE-2026-66066 is a severe supply-chain-adjacent vulnerability: a trust assumption between Rails Active Storage and libvips that turned out to be false. The fix is simple, but the blast radius of a successful exploit is enormous — full credential compromise of the Rails application and potentially its entire connected infrastructure. Every Rails team using Active Storage with the default libvips processor should treat this as a patch-now, rotate-secrets-immediately incident. The existence of a public PoC claiming RCE capability means the window for safe patching is measured in hours, not days.

---

Sources: The Hacker News: Critical Rails Flaw Could Let Unauthenticated Attackers Read Server Files via Image Uploads, Rails Security Advisory GHSA-xr9x-r78c-5hrm, Ethiack Research: Kindarails2Shell Rails RCE, GMO Flatt Security: kindarails2shell, Public Patch Commit, NVD CVE-2026-66066