Title: Critical Active Storage Flaws in Rails Let Uploaded Files Reach ImageMagick and FFmpeg Unchecked
Summary:
Rails disclosed two Active Storage flaws on November 4, fixed in 8.1.4.1 and 8.0.5.2. The critical one, GHSA-f3w6-w445-fwh9 (CVSS 9.8, no CVE identifier yet), lets an unauthenticated attacker upload a crafted file that reaches ImageMagick as soon as the attachment initializes — no variant, preview, or analyze call needed. ImageMagick picks a processing “coder” from the file’s content, and some coders operate on files named inside the image rather than on the image itself; Active Storage restricted none of them, so a coder such as MSL could be driven to write arbitrary files on the server and, where attachments are stored with the Disk service, read files the app process can read — typically secret_key_base and credentials for other systems, opening the way to RCE or lateral movement. An app is affected when it uses ImageMagick for Active Storage processing (variant_processor = :mini_magick, the default for apps on load_defaults 6.1 or earlier), accepts untrusted uploads, and runs under an ImageMagick policy that does not already deny the coders — Rails notes that the default Debian and Ubuntu policies do not. A second flaw the same releases fix, GHSA-v924-7rp8-4mxh (8.8), kept the uploaded file’s extension on tempfiles handed to ImageMagick and FFmpeg, letting the extension pick the decoder; an FFmpeg with AviSynth support would evaluate an .avs upload as a script, enabling file disclosure or code execution. The fix ships a bundled ImageMagick security policy (requires mini_magick ≥ 5.1 on :mini_magick apps or the app raises on boot); GraphicsMagick reads no ImageMagick policies, and apps that override MiniMagick’s environment or CLI plumbing must carry the rules in the system policy.xml themselves. Both advisories credit HackerOne researchers (ryotak for the ImageMagick flaw, pirikara for the extension flaw) and say nothing about exploitation in the wild. Patch first; neither flaw’s advisory explains how to check whether an app has already been targeted. Both add a cleanup duty: upgrading closes the hole but does not undo a disclosure that already happened, so if the app stored attachments with the Disk service or could have been reached via the AviSynth path, treat every secret the app process can read — secret_key_base, the master key and everything in config/credentials.yml.enc, storage and database credentials, third-party tokens — as exposed and change it, without keeping any exposed secret as a fallback.
References:
- Rails advisory GHSA-f3w6-w445-fwh9: possible arbitrary file write and read in Active Storage image analysis
- Rails advisory GHSA-v924-7rp8-4mxh: possible arbitrary file read and remote code execution in Active Storage video previews, analysis and image processing
- The Hacker News: Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads