Skip to content
Hacker Posts

Rails Active Storage: unauth file write via ImageMagick, 9.8

Active Storage 8.1.4.1 and 8.0.5.2 fix a critical ImageMagick flaw (GHSA-f3w6-w445-fwh9) that lets an unauthenticated upload write — and sometimes read — arbitrary server files. No CVE yet.

Published 3 min read
cverailsrubyadvisory

Rails shipped Active Storage 8.1.4.1 and 8.0.5.2 on November 4 to fix a critical flaw that lets an unauthenticated attacker write arbitrary files on the server by uploading a crafted file. The primary source is the Rails advisory GHSA-f3w6-w445-fwh9, scored 9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). No CVE is assigned yet — the advisory lists "No known CVE." The Hacker News also reported it.

What the bug does

ImageMagick picks a decoder ("coder") based on file content, and some coders — the MSL coder in particular — read and write files whose names the input itself supplies. Active Storage runs ImageMagick's analyzer whenever a file is attached, and it did not restrict those coders. An attacker who uploads a crafted file (an SVG that reaches the MSL coder, per the advisory) can therefore write arbitrary files to paths the app process can reach.

Two details make this worse than a typical image-parsing bug:

  • No variant, preview, or analyze call is needed. The advisory states plainly: "Attaching the upload is sufficient."
  • Apps using the Disk service can also read arbitrary files the process can access — secret_key_base, external credentials — turning the write primitive into a secrets-disclosure one.

A second, related advisory, GHSA-v924-7rp8-4mxh (CVSS 8.8), covers temporary filenames that kept the upload's extension when passed to ImageMagick and FFmpeg, letting an attacker influence decoder selection. Both are fixed in the same releases, which the maintainers' oss-security post says close 21 security issues in total.

Affected and fixed versions

  • Affected: Active Storage >= 8.1, < 8.1.4.1 and < 8.0.5.2.
  • Fixed: 8.1.4.1 and 8.0.5.2 (commits 468aa9a for 8.1, ea8c401 for 8.0).
  • Release series older than 8.0 are unsupported and will not get a fix.

The exposed configuration is an app that accepts uploads from untrusted users, uses config.active_storage.variant_processor = :mini_magick, and runs ImageMagick under a policy that doesn't deny the relevant coders — which, the advisory notes, the default Debian and Ubuntu policies do not.

Exploitation status

Not confirmed in the wild. Rails says one attack chain was reported to it and that it does "not assume it is the only one that exists." The flaw was reported by HackerOne researcher Ry0taK of GMO Flatt Security. There is no public PoC in the advisory and the bug is not in CISA's KEV catalog.

Action checklist

  1. Upgrade to Active Storage 8.1.4.1 or 8.0.5.2. This is the clean fix.
  2. If you can't upgrade immediately, harden the ImageMagick policy. Copy the rules from the shipped activestorage/lib/active_storage/image_magick/policy.xml into your system policy (e.g. /etc/ImageMagick-7/policy.xml). At minimum, deny the MSL coder, the Ghostscript coders, and the gs delegate. Note GraphicsMagick does not read ImageMagick policies.
  3. Move to mini_magick >= 5.1 if you use the :mini_magick processor.
  4. If attachments use the Disk service, rotate secrets. Treat secret_key_base and any credentials readable by the app process as potentially exposed and rotate them.

Context

This is the second critical Active Storage image-analysis flaw this year, after CVE-2026-66066 in July hit apps using libvips; the ImageMagick path is the one left exposed this time. The recurring theme is that passing untrusted uploads to a content-sniffing image library hands the attacker a decoder-selection primitive, and the default distro policies are permissive enough to turn that into file write. If you run Active Storage with user uploads, the policy file is as load-bearing as the gem version.

Related stories