CVE-2026-66066, scored 9.5 under CVSS, can let an unauthenticated attacker read arbitrary files from a Rails application server by abusing image uploads — potentially exposing secret_key_base, the Rails master key, database passwords, cloud storage credentials and API tokens.
CVE-2026-66066 and the affected Rails releases
Two independent research teams — Ethiack and GMO Flatt Security — reported that the flaw affects Rails releases that use libvips for Active Storage image processing. They list the practical 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 are affected only when Active Storage is configured to use Vips; libvips was not the default processor in Rails 6. The official advisory frames the package impact broadly as activestorage < 7.2.3.2. Rails 7.0 and 7.1 are end of life and have no fixed releases; applications on those branches must upgrade to Rails 7.2.3.2 or later.
How Active Storage and libvips combine to enable arbitrary file reads
The vulnerability sits at the trust boundary between Active Storage and libvips. Rails’ advisory explains that libvips supports loaders, savers and other operations, some of which are marked "unfuzzed" or "untrusted" because they are unsafe for hostile input. Active Storage did not block those unsafe operations; a crafted upload can invoke one of them and disclose files readable by the Rails worker.
Rails warned that "Generating variants is not a separate requirement" — a vulnerable application does not need to expose a dedicated resize or thumbnail operation. The public patch shows that both the Vips analyzer and transformer previously passed untrusted attachments to the unsafe operations, giving an attacker a file‑read primitive. What an attacker could then do depends on the files and credentials they extract; the advisory notes those secrets "may enable remote code execution (RCE) or lateral movement into connected systems."
Remediation: patches, configuration flags, and secrets rotation
Rails released fixes and recommends upgrading to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1. The patch calls Vips.block_untrusted(true) when Active Storage starts. Operators who cannot immediately update Rails can set the environment variable VIPS_BLOCK_UNTRUSTED when running libvips 8.13 or later, or call Vips.block_untrusted(true) when using ruby-vips 2.2.1 or later. Rails says earlier libvips versions cannot block these operations; affected installations must either upgrade libvips to 8.13 or later or remove libvips from the application.
Because applying the code patch does not invalidate credentials already stolen, Rails tells operators to rotate every secret readable by the application process, explicitly naming secret_key_base, the master key and decrypted credentials, database credentials, Active Storage service keys, and third‑party tokens.
Patched installations require libvips 8.13 or later and, when ruby-vips is installed, ruby-vips 2.2.1 or later. Applications using MiniMagick are not exposed through this specific attack path.
Attribution, proof‑of‑concept status, and observed exploitation
Rails credited André Baptista, Bruno Mendes and Rafael Castilho of Ethiack, and RyotaK of GMO Flatt Security with independently reporting the issue. As of 17:30 UTC on July 29, 2026, neither research team had published a proof‑of‑concept, and exact‑term searches by The Hacker News found no exploit repository in indexed GitHub, GitLab, Exploit‑DB or Packet Storm. Neither Rails nor the researchers reported in‑the‑wild exploitation at publication. The Hacker News reported that it had contacted the Rails security team about exploitation and affected versions, and Ethiack about the attack chain.
The Hacker News’ review at 17:30 UTC on July 29 also found that CVE‑2026‑66066 was not listed in version 2026.07.27 of CISA's Known Exploited Vulnerabilities catalog.
How web operators, open‑source maintainers, and potential attackers are affected
- Web operators and security teams: must prioritize upgrades to Rails 7.2.3.2, 8.0.5.1 or 8.1.3.1; upgrade libvips to 8.13 or later and ruby‑vips to 2.2.1 when used; set VIPS_BLOCK_UNTRUSTED or call Vips.block_untrusted(true) if immediate framework upgrades are not possible; and rotate all secrets readable by the Rails process.
- Open‑source maintainers (libvips and ruby‑vips): need to ensure that libvips 8.13 and ruby‑vips 2.2.1 provide the blocking capability Rails relies on, and to communicate which loaders or savers remain "untrusted" in builds that include third‑party libraries.
- Adversaries and defenders watching for exploitation: defenders should monitor for misuse of Active Storage endpoints and exfiltration patterns; researchers and attackers will likely study the undisclosed malicious format and file‑read construction once technical details are published.
Rails said further technical details will be released no later than August 28, 2026. Until then, operators should assume a practical file‑read primitive exists in the listed, Vips‑using deployments and act accordingly: apply the patches, tighten libvips configuration, and rotate any secrets the application can access.
https://thehackernews.com/2026/07/critical-rails-flaw-could-let.html
