[CVE-2026-66066] Possible arbitrary file read and remote code execution in Active Storage variant processing - Security Announcements - Ruby on Rails Discussions

= 40rem)" rel="stylesheet" data-target="discourse-ai_desktop" /><br>= 40rem)" rel="stylesheet" data-target="discourse-reactions_desktop" /><br>= 40rem)" rel="stylesheet" data-target="poll_desktop" />

= 40rem)" rel="stylesheet" data-target="desktop_theme" data-theme-id="5" data-theme-name="ruby on rails theme"/>

[CVE-2026-66066] Possible arbitrary file read and remote code execution in Active Storage variant processing

Security Announcements

announcement,<br>security

rafaelfranca

(Rafael França)

July 29, 2026, 3:37pm

See Possible arbitrary file read and remote code execution in Active Storage variant processing · Advisory · rails/rails · GitHub

Impact

In its default configuration, a Rails application that displays image variants may allow an<br>unauthenticated attacker to read arbitrary files from the server, including the process environment.<br>That environment typically holds secret_key_base and often credentials for external systems, which<br>may in turn allow escalation to remote code execution or lateral movement to those systems.

Details

libvips reads and writes file formats through “loaders” and “savers” (or more generally<br>“operations”), many of which are backed by third-party libraries. It marks some of these operations<br>as “unfuzzed”, meaning they are unsafe for untrusted content, and several handle formats unrelated<br>to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload<br>a crafted file and cause a variant to be generated from it may be able to invoke one.

We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause<br>disclosure of the contents of arbitrary files accessible on the filesystem of the targeted<br>application. One specific attack chain has been reported to us (see “Disclosure” below), but we do<br>not assume it is the only one that exists.

Affected applications

An application is affected if it meets all of these requirements:

Uses libvips for Active Storage image processing. This is config.active_storage.variant_processor = :vips,<br>which load_defaults 7.0 set and no later default has changed.

Allows image uploads from untrusted users.

Generating variants is not a separate requirement.

Mitigation

Upgrade to a fixed version of activestorage.

The minimum version of libvips must be upgraded to >= 8.13.

Change secret_key_base and change any secrets accessible in the application environment (see “Expire and change secrets” below)

Earlier versions of libvips () cannot disable unfuzzed operations at all, and Active Storage<br>will raise an exception during boot in such an unsecurable environment.

Expire and change secrets

Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already<br>occurred. An affected application should treat every secret readable by the application process as<br>potentially exposed and change it, including:

secret_key_base

The master key, whether stored in config/master.key or supplied as RAILS_MASTER_KEY, along<br>with everything in config/credentials.yml.enc that it decrypts

Credentials for the Active Storage service, such as S3, GCS, or Azure keys

Database credentials

Tokens and keys for any third-party service the application calls

Changing secret_key_base expires active sessions and requires users to log in again. Encrypted<br>cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.

Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret<br>as a fallback.

Workarounds

If libvips is being used, there are no workarounds available other than removing the<br>dependency on libvips from the application. Some applications may have ruby-vips declared as a<br>dependency only for image analysis, and those applications may be able to simply remove ruby-vips<br>from the Gemfile to remove libvips from the application. Applications that do not use Active Storage<br>can remove ruby-vips from the Gemfile to avoid the boot-time checks.

If libvips >= 8.13 is present on the system, applications can disable the unfuzzed operations<br>without upgrading Rails by setting the VIPS_BLOCK_UNTRUSTED environment variable, which libvips<br>reads while initializing.

Applications also running ruby-vips >= 2.2.1 or later can instead call<br>Vips.block_untrusted(true) from an initializer.

Releases

The fixed releases are available at the normal locations.

Versions affected

activestorage activestorage >= 8.0, activestorage >= 8.1,<br>Disclosure

Technical details of the attack chain are intentionally omitted from this advisory. They would add<br>nothing to an administrator’s decision to upgrade, while making it substantially easier to attack<br>applications that have not yet done so.

Details will be disclosed no later than 2026-08-28, via the Rails Security<br>Announcements forum.

Credit

This...