Ruby on Rails has released fixes for a critical Active Storage vulnerability that could let unauthenticated attackers read arbitrary files from application servers through crafted image uploads.
Tracked as CVE-2026-66066 (CVSS score: 9.5), the flaw can expose the Rails process environment and secrets such as secret_key_base, the Rails master key, database passwords, cloud storage credentials, and API tokens. Those secrets may enable remote code execution (RCE) or lateral movement into connected systems.
Affected applications use libvips for Active Storage image processing and accept image uploads from untrusted users. Rails selects Vips under load_defaults 7.0, and later defaults retain it.
Ethiack and GMO Flatt Security list the affected ranges as Rails 7.0.0 through 7.2.3.1, Rails 8.0.0 through 8.0.5, and Rails 8.1.0 through 8.1.3. Rails 6.0.0 through 6.1.7.10 releases are affected only when Active Storage is configured to use Vips, which was not the default processor in Rails 6.
The official advisory lists a broader package range: activestorage < 7.2.3.2. Both research teams place the practical Vips attack path at Rails 6.0 and later. Applications using MiniMagick are not exposed through this specific attack path. Rails 7.0 and 7.1 are end of life and have no fixed releases, so applications on those branches must upgrade to Rails 7.2.3.2 or later.
Operators should upgrade to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 and rotate every secret readable by the application process. Patched installations require libvips 8.13 or later and, when ruby-vips is installed, ruby-vips 2.2.1 or later.
Neither research team had published a proof-of-concept (PoC) as of 17:30 UTC on July 29, 2026. Exact-term searches by The Hacker News found no exploit repository in indexed GitHub, GitLab, Exploit-DB, or Packet Storm results at the same time. Rails warned that applying the patch does not invalidate credentials that may already have been stolen.
The flaw sits at the trust boundary between Active Storage and libvips. The Rails security advisory says libvips supports loaders, savers, and other operations, some backed by third-party libraries and marked “unfuzzed” or “untrusted” because they are unsafe for hostile input. Active Storage did not block them, allowing a crafted upload to invoke one and disclose files readable by the Rails worker.
A vulnerable application does not need to expose a dedicated resize or thumbnail operation. “Generating variants is not a separate requirement,” Rails said. The public patch also shows that both the Vips analyzer and transformer passed untrusted attachments to the unsafe operations.
A successful request gives the attacker an arbitrary file-read primitive. Code execution or lateral movement would depend on what the attacker extracts and what those credentials can reach. Rails tells operators to rotate secret_key_base, the master key and decrypted credentials, database credentials, Active Storage service keys, and third-party tokens.
The patch calls Vips.block_untrusted(true) when Active Storage starts. Applications that cannot immediately update Rails can set VIPS_BLOCK_UNTRUSTED when running libvips 8.13 or later, or call Vips.block_untrusted(true) with ruby-vips 2.2.1 or later. Rails says earlier libvips versions cannot block these operations, so applications must upgrade libvips or remove it from the application.
Rails credited André Baptista, Bruno Mendes, and Rafael Castilho of Ethiack, and RyotaK of GMO Flatt Security, with independently reporting the issue. The researchers have not disclosed the malicious format, file-read construction, or RCE chain. Rails said further technical details will be released no later than August 28, 2026.
The Hacker News has contacted the Rails security team about exploitation and affected versions, and Ethiack about the attack chain.
Neither Rails nor the researchers reported in-the-wild exploitation at publication. A review by The Hacker News at 17:30 UTC on July 29 found that CVE-2026-66066 was not listed in version 2026.07.27 of CISA’s Known Exploited Vulnerabilities catalog.
No reliable count of vulnerable applications or named victims is available. The 9.5 score describes severity under CVSS, not how many deployments are exposed: a vulnerable deployment must also use Vips, accept untrusted image uploads, and include an exploitable operation in its libvips build.
