Rails Active Storage: Critical Arbitrary File Read/Write via ImageMagick Image Analysis (CVE-2026-122006)

What happened

Rails disclosed a security advisory (GHSA-f3w6-w445-fwh9, CVE-2026-122006, CVSS 9.8) for Active Storage. According to the advisory, an application that processes attachments with ImageMagick via MiniMagick can have ImageMagick's coder selection abused. This is the default for apps on load_defaults 6.1 or earlier, meaning config.active_storage.variant_processor = :mini_magick. Some ImageMagick coders act on files named inside the uploaded image rather than on the image data itself, and Active Storage did not constrain which coders could run. The analyzer runs automatically when a file is attached. Simply attaching a crafted file can be enough to trigger it. No variant, preview, or explicit analyze call is required. Rails states an unauthenticated attacker may achieve arbitrary file write, and, when attachments use the Disk service, arbitrary file read of anything the app process can read. One concrete attack chain has been reported to Rails, and they note they do not assume it is the only one. Affected versions are activestorage < 8.0.5.2 and >= 8.1, < 8.1.4.1. Exploit status is listed as PoC-public.

Why it matters

This hits any Rails app that meets three conditions. First, it uses the MiniMagick variant processor. Second, it runs ImageMagick under a policy that does not already deny the relevant coders. Rails specifically states that the ImageMagick policies packaged by Debian and Ubuntu do not. Third, it accepts file uploads from untrusted users. Readable files commonly include secret_key_base, the contents of config/credentials.yml.enc, and database or third-party service credentials, which the advisory says can escalate to RCE or lateral movement into connected systems. Given the CVSS 9.8 rating, the no-auth requirement, and the public PoC, this is a high-priority patch item for any Rails shop accepting user uploads.

What defenders should do now

• Upgrade activestorage to a fixed version (>= 8.0.5.2 or >= 8.1.4.1). The fix requires mini_magick >= 5.1. Apps on an older mini_magick will raise an exception on boot once upgraded.
• If you cannot upgrade immediately, apply the workaround. Merge the deny-rules from activestorage/lib/active_storage/image_magick/policy.xml into your host's ImageMagick policy.xml (for example /etc/ImageMagick-7/policy.xml). At a minimum, deny the MSL coder, the Ghostscript coders and the gs delegate, and the PS/PDF-family coders.
• If your app overrides MiniMagick.cli_env or cli_prefix, or supplies its own MiniMagick::Shell, the shipped policy will not apply automatically. You must enforce the rules in the system policy yourself. GraphicsMagick does not read ImageMagick policies.
• If attachments are stored via the Disk service, treat secret_key_base and all credentials readable by the app process as compromised, and rotate them rather than assuming no exploitation occurred.
• Hunting angle: review upload and attachment logs for crafted files with unusual embedded filenames or atypical ImageMagick coder signatures (for example MSL, PS/EPS/PDF payloads) attached outside normal image-upload flows, and check for unexpected file writes that correlate with attachment creation timestamps.

Developing intel

This is same-day, developing intel based solely on the Rails security advisory. Details beyond what Rails has published, such as the specific attack chain, are not yet public. Track the original advisory for updates: GHSA-f3w6-w445-fwh9.