| Package | Affected versions | Patched versions |
|---|---|---|
| activestorage | ≥ 8.0.0.beta1, < 8.0.5.1≥ 8.1.0.beta1, < 8.1.3.1< 7.2.3.2 | 8.0.5.18.1.3.17.2.3.2 |
In its default configuration, a Rails application that displays image variants may allow an
unauthenticated attacker to read arbitrary files from the server, including the process environment.
That environment typically holds secret_key_base and often credentials for external systems, which
may in turn allow escalation to remote code execution or lateral movement to those systems.
libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload 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 disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists.
An application is affected if it meets all of these requirements:
config.active_storage.variant_processor = :vips,
which load_defaults 7.0 set and no later default has changed.Generating variants is not a separate requirement.
activestorage.>= 8.13.secret_key_base and change any secrets accessible in the application environment (see "Expire and change secrets" below)Earlier versions of libvips (< 8.13) cannot disable unfuzzed operations at all, and Active Storage
will raise an exception during boot in such an unsecurable environment.
Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including:
secret_key_baseconfig/master.key or supplied as RAILS_MASTER_KEY, along
with everything in config/credentials.yml.enc that it decryptsChanging secret_key_base expires active sessions and requires users to log in again. Encrypted
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 as a fallback.
If libvips < 8.13 is being used, there are no workarounds available other than removing the
dependency on libvips from the application. Some applications may have ruby-vips declared as a
dependency only for image analysis, and those applications may be able to simply remove ruby-vips
from the Gemfile to remove libvips from the application. Applications that do not use Active Storage
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
without upgrading Rails by setting the VIPS_BLOCK_UNTRUSTED environment variable, which libvips
reads while initializing.
Applications also running ruby-vips >= 2.2.1 or later can instead call
Vips.block_untrusted(true) from an initializer.
The fixed releases are available at the normal locations.
Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so.
Details will be disclosed no later than 2026-08-28, via the Rails Security Announcements forum.
This issue was responsibly reported by 0xacb, s3np41k1r1t0 and castilho from Ethiack, and RyotaK from GMO Flatt Security Inc..
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free