Rails Active Storage EUVD-2026-51270

The primary fix is upgrading the rails gem to 7.2.3.2, 8.0.5.1, or 8.1.3.1 as appropriate, and simultaneously upgrading libvips to version 8.13 or later - Rails patching alone is insufficient if the system libvips remains below 8.13. Following any confirmed or suspected exposure, all secrets readable by the application process must be rotated: secret_key_base (which invalidates active user sessions and affects encrypted cookies, signed cookies, signed global IDs, and Active Storage signed URLs), the Rails master key (RAILS_MASTER_KEY or config/master.key) along with all config/credentials.yml.enc contents it decrypts, Active Storage backend credentials (S3, GCS, or Azure keys), database credentials, and all third-party API tokens. Do not retain an exposed secret as a rotation fallback. If an immediate upgrade is blocked and libvips >= 8.13 is already installed, set the environment variable VIPS_BLOCK_UNTRUSTED=1 as a temporary workaround - libvips reads this at startup to block unfuzzed operations. Applications with ruby-vips >= 2.2.1 can alternatively call Vips.block_untrusted(true) from an initializer. If libvips < 8.13 is in use, no in-place workaround exists: the only option is removing the ruby-vips dependency from the Gemfile (feasible for applications using ruby-vips only for image analysis rather than variant generation). WAF-based mitigations are assessed as having highly limited and configuration-specific effectiveness per linked research from Ethiack and GMO Flatt Security and should not be relied upon as a primary control.