The bug comes down to how libvips picks a loader: it decides how to open a file by inspecting it, not by trusting the extension your upload form validated, so a payload that passes as an image can be routed to the MATLAB, NIfTI, SVG or PDF reader instead, and Active Storage did not switch those readers off even though some are unsafe on files that come from strangers [1]. That routing only becomes dangerous once the variant actually gets built, because building it is what executes the loader. According to a member of the Rails core team, an app that displays image variants in its default configuration may let an unauthenticated attacker read arbitrary files including the process environment, which typically holds secret_key_base and often credentials for external systems, and that opens escalation to remote code execution or lateral movement into those systems [2].
That's also why the gem version alone is a weak inventory key. The affected releases are the 7.0 line before 7.2.3.2, 8.0 before 8.0.5.1 and 8.1 before 8.1.3.1 [4]; apps configured to use the ImageMagick processor rather than vips are out of scope [6]; and Rails 6.0.0 through 6.1.7.10 is affected only where Active Storage was configured outside its defaults, so a stock 6.x install is not exposed, per Ethiack [7]. Ethiack also flags every user-facing feature that accepts an upload and later serves a processed version, naming avatars, thumbnails and profile pictures, plus third-party software built on Rails that you did not write [8]. The question per app is which features serve variants and what libvips is underneath, not only what Gemfile.lock says.
What actually determines your options here is the host layer, specifically which libvips version is installed. With libvips 8.13 or later present, setting the VIPS_BLOCK_UNTRUSTED environment variable disables the unfuzzed operations at library init and does so without a Rails upgrade; below 8.13, the Rails team says there is no workaround other than removing the libvips dependency [10]. The full guidance runs on both tracks, Rails to a fixed version and libvips to 8.13 or later, then rotation of the master key, database credentials, S3, GCS or Azure keys and third-party tokens [9].
Details and exploit code were withheld to give operators time to patch, and other researchers then reverse-engineered the attack [13]. Help Net Security's writeup ran on August 3 [14]; measured from the July 29 release, that is five days of head start [15]. Akamai says it coordinated with Ethiack before disclosure and has deployed WAF rules for the attack, while both Akamai and Ethiack say rules matched to known exploit patterns do not substitute for the patch and the rotation [11]. Rotation is the step most likely to slip. An app patched this week with its old secret_key_base still in place is closed against the read and still holding the key an earlier read would have taken [9].</body_markdown> </invoke>
