A newly disclosed vulnerability in Ruby on Rails, tracked as CVE-2026-66066, gives unauthenticated attackers a path to read sensitive files directly off a server — and in some configurations, escalate that access into full remote code execution. The flaw sits in Active Storage, the framework’s built-in system for handling file uploads and generating image variants, and it affects any application that lets untrusted users upload images while relying on the libvips library for processing.

Where the Weakness Lives

Rails has used libvips as its default image-variant processor since the 7.0 release, configured through config.active_storage.variant_processor = :vips. Libvips itself handles a wide range of file formats through a collection of loaders and savers, many of which depend on third-party libraries. Some of those operations are explicitly marked by the library’s maintainers as “unfuzzed” — a signal that they haven’t been hardened against malicious input and shouldn’t be exposed to untrusted files.

The problem is that Active Storage never disabled those unfuzzed code paths. A number of them handle file formats that have nothing to do with ordinary web images, meaning a specially crafted upload can invoke functionality the application never intended to expose to the public. Researchers demonstrated that this can be chained into disclosure of arbitrary files readable by the application process — including, critically, the environment variables where secrets like secret_key_base and cloud credentials commonly reside.

Who Is Exposed

An application is vulnerable if it uses libvips for Active Storage variant processing (the Rails default since version 7.0) and accepts image uploads from untrusted users. Notably, the app doesn’t even need to actively generate variants for the exposure to exist — the vulnerable code path can be reachable regardless.

• Affected versions: activestorage below 7.2.3.2, the 8.0.x line below 8.0.5.1, and 8.1.x below 8.1.3.1.
• Fixed releases are already available through standard Rails distribution channels.
• A secure configuration requires libvips 8.13 or later; older libvips builds cannot disable the risky operations at all, and patched Active Storage will refuse to boot in that state.

Patching Isn’t the Whole Story

Upgrading stops further exploitation, but it does nothing to recover secrets that may already have been exposed. The Rails security team is urging administrators to treat every secret reachable by the application process as potentially compromised and rotate it as a precaution. That list is longer than it might first appear: secret_key_base, the master key stored in config/master.key or the RAILS_MASTER_KEY environment variable, everything decrypted from credentials.yml.enc, Active Storage service keys for S3, GCS, or Azure, database credentials, and any third-party API tokens accessible to the process.

Rotating secret_key_base carries its own operational cost — it invalidates active user sessions and any signed or encrypted cookies, signed global IDs, and existing Active Storage URLs, forcing everyone to log back in. Rails maintainers are clear that this rotation should be treated as a one-time cleanup rather than something to defer indefinitely; an exposed secret should never be kept in service as a fallback.

Stopgap Options for Teams That Can’t Patch Immediately

For organizations that can’t upgrade Rails right away, there are limited mitigations. On libvips 8.13 or newer, setting the VIPS_BLOCK_UNTRUSTED environment variable blocks the risky operations at library initialization. Applications running ruby-vips 2.2.1 or later can achieve the same result programmatically by calling Vips.block_untrusted(true) from an initializer. On libvips versions older than 8.13, there is no safe workaround short of removing the ruby-vips dependency entirely, which may be viable for apps that only use it for image analysis rather than Active Storage.

Coordinated Disclosure and Withheld Detail

The flaw was reported responsibly by researchers 0xacb, s3np41k1r1t0, and Castilho of Ethiack, along with RyotaK of GMO Flatt Security. The Rails team has deliberately withheld the specific technical attack chain to give operators time to patch before a full write-up appears, with complete disclosure planned no later than August 28, 2026, via the official Rails Security Announcements forum.

Given the combination of an unauthenticated entry point, a default configuration that many production apps share, and a plausible path to remote code execution, teams running Rails with Active Storage and libvips should treat this as a same-week priority: patch, rotate credentials, and verify that untrusted operations are blocked before reopening upload functionality to the public.