libvips supports certain file-loading operations that its own maintainers flag as unsafe for hostile input. Active Storage did not restrict access to these operations. It passed untrusted uploaded files directly into them. No special upload endpoint was needed — even standard variant generation triggered the vulnerable path.

An attacker uploads a specially crafted file (reportedly a MATLAB/HDF5 format file) through any public upload form. libvips processes it and reads internal server files. The attacker recovers SECRET_KEY_BASE (a master signing key Rails uses to verify session data). With that key, an attacker can forge authenticated session tokens, enabling RCE (remote code execution — running arbitrary commands on the server) or lateral movement (moving from one compromised system into others connected to it).

• Unexpected or malformed file types appearing in upload logs (MATLAB, HDF5, or similar scientific formats submitted to image upload endpoints)
• Anomalous outbound network requests from your Rails worker processes, particularly curl-style callbacks to external addresses
• Unrecognised session tokens appearing in application logs after no corresponding login event

1. Upgrade Rails to 7.2.3.2, 8.0.5.1, or 8.1.3.1 immediately. Rails 7.1 and earlier are end-of-life and will not receive a backport.
2. If you cannot patch immediately and run libvips 8.13 or later, set the environment variable VIPS_BLOCK_UNTRUSTED=1 or call Vips.block_untrusted(true) via ruby-vips 2.2.1 or later.
3. Rotate all secrets readable by the application process: secret_key_base, master key, database credentials, cloud storage keys, and third-party API tokens.

Rails trusts the content type declared by the client to determine whether a file is an image. libvips ignores that declaration and inspects the file's internal bytes instead. An attacker exploits this disagreement by crafting a file that claims to be a MATLAB image, which tricks libvips into handing it to a chain of libraries that ultimately reads an attacker-chosen file from the server and returns its contents.

An unauthenticated attacker uploads a specially crafted file to any vulnerable image upload endpoint. The server processes it as an image, reads a sensitive file — such as the credentials database — and returns its contents to the attacker. Armed with those secrets, the attacker can forge user sessions and execute code. Critically, VulnCheck found that patching to 8.1.3.1 blocks the file-read path but does not neutralise a separate deserialization gadget, meaning RCE remains possible on patched servers given a valid signature.

Check server logs for image upload requests containing MATLAB or HDF5 file signatures. Look for unexpected outbound connections from your Rails process. Rails has published forensic tools specifically to detect exploitation attempts — run them.

1. Patch to the latest Rails release immediately and apply all available security updates.
2. Restrict image upload endpoints to authenticated users where possible.
3. Run Rails' published forensic detection tools and review logs for signs of prior exploitation.