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.
Ethiack told The Hacker News that the Debian, Ubuntu, and Rails-generated Docker environments cited in its research include the required libraries by default and are exposed to the vulnerability. Other distributions and base images may not be exploitable.
The Rails Security Team told The Hacker News that the researchers’ affected range is accurate. It said the public advisory covers Rails releases under security support, meaning Rails 7.2, 8.0, and 8.1, while Rails 6.x is also affected when Vips is enabled, which was not the default at the time. Applications using MiniMagick are not exposed through this specific attack path. Rails 7.1 and earlier are end of life and will receive no backport, so affected applications 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. A third-party GitHub repository published after that check 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 code 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. Ethiack has since published its own chain, which uses the same MATLAB/HDF5 file-read primitive but reaches RCE through CVE-2025-24293 rather than the third-party repository’s Marshal payload.
In a new technical analysis, Ethiack said the file-read primitive uses a crafted MAT v7.3 file, an HDF5 container with an external dataset pointing to an attacker-chosen file path. The payload begins with the literal MATLAB 5.0 string expected by libvips, while its version field causes libmatio to process it as HDF5 and follow the external reference.
On the direct-upload path, Active Storage accepts the client-supplied content_type, allowing an attacker to label the MAT payload as image/png. Ethiack said a legitimate variation key can then be replayed against the malicious blob, causing Active Storage to process it with libvips and return the target file’s bytes through generated image pixels.
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. Ethiack said its RCE chain uses that access to recover secret_key_base from encrypted credentials or the process environment, forge a malicious variation key, and exploit CVE-2025-24293. The firm said the Vips transformer allowed the forged variation to invoke instance_eval and execute Ruby code. 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 has also published a forensic toolkit to establish an application’s exposure window and search object storage and Active Storage records for evidence of exploitation.
Rails credited André Baptista, Bruno Mendes, and Rafael Castilho of Ethiack, and RyotaK of GMO Flatt Security, with independently reporting the issue. Ethiack has now published the previously withheld malicious format, file-read method, and RCE chain.
The Rails Security Team told The Hacker News that it is not aware of exploitation or attempted exploitation before or after disclosure. It also said Rails has no telemetry or reasonable estimate for how many applications use Active Storage with Vips and accept untrusted image uploads. Ethiack told The Hacker News that it first reported the vulnerability to Rails on July 22. Its new analysis says the firm completed an initial working PoC on July 21 and Rails acknowledged the report on July 23.
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.
Update [July 30, 2026]: This story has been updated to include comments from the Rails Security Team and Ethiack, along with details about a newly published third-party proof-of-concept.
Update [July 31, 2026]: This story has been updated with Ethiack’s technical analysis of the file-read-to-RCE chain and Rails’ forensic tooling.
