ARTICLE ORIGINAL MAG212 CYBER

Rails Active Storage GHSA-f3w6-w445-fwh9: Upgrade to 8.0.5.2 or 8.1.4.1, Then Rotate Your Secrets

novembre 5, 2026 · El Mostafa Ouchen

Rails Active Storage: Upgrade, Then Rotate Your Secrets

Rails released 8.0.5.2 and 8.1.4.1 on November 4, fixing 21 security issues. The most serious, GHSA-f3w6-w445-fwh9 (CVSS 9.8), lets an untrusted image upload write files on the server, and read them on apps that store files on local disk, through a permissive ImageMagick setup. For those apps, upgrading is only half the job: secrets the app could read, including secret_key_base, need rotating too.

Faits clés

ArticleDétail
ReleasesRails 8.0.5.2 and 8.1.4.1, November 4, 2026
Portée21 advisories: 1 Critical, 4 High, 13 Medium, 3 Low; GHSA IDs only, no CVEs listed
CritiqueGHSA-f3w6-w445-fwh9: Active Storage image analysis file write/read, CVSS 9.8, no login
HautGHSA-v924-7rp8-4mxh: media processing via file extension, CVSS 8.8, needs an upload account
Affectedactivestorage before 8.0.5.2, and 8.1 before 8.1.4.1
ExploitationNone reported in the advisories
DeadlineRails 8.0 security support ends November 7, 2026

An early version of one report gave the critical flaw a CVE number. We found no such record: the advisory says “No known CVE”.

Are you affected by the critical flaw?

All three must be true:

  • The app uses :mini_magick for image processing. That is the default under load_defaults 6.1 or earlier.
  • The system ImageMagick policy does not block the dangerous coders. Stock Debian and Ubuntu policies don’t.
  • Untrusted users can upload files. Simply attaching an upload is enough to trigger analysis.

Déposer read additionally needs the Disk storage service. That’s what makes secret_key_base and other secrets reachable.

Diagram of two Rails Active Storage flaws through ImageMagick and media decoders, with fixes and secret rotation
The two Active Storage paths and what to do after patching. MAG212 CYBER original diagram, based on the Rails advisories.

The second flaw: a file extension that picks the decoder

GHSA-v924-7rp8-4mxh affects apps that analyze or preview video and audio. The temporary file kept the uploader’s chosen extension, which steers ffprobe, ffmpeg or ImageMagick toward a particular decoder. One code-execution route needs FFmpeg built with --enable-avisynth plus AviSynthPlus installed, which distribution packages usually don’t enable. The fix keeps an extension only when it matches the recorded content type.

How to fix it properly

  1. Upgrade every image that runs the app, web and background workers alike. Analysis often runs in workers.
  2. Use mini_magick 5.1 or later. Older versions make the fixed release raise an error at boot.
  3. Let Rails’ policy do its job. The fixed release ships its own restrictive ImageMagick policy. If you render PDF or PostScript, re-allow only what you need. If you override MiniMagick.cli_env or use cli_prefix, copy the rules into the system policy yourself.
  4. Rotate secrets on the Disk service: secret_key_base and every secret the app process can read.
  5. Can’t upgrade today? Harden the system policy.xml, and remove VideoPreviewer, VideoAnalyzer and AudioAnalyzer from the config.

Read-only checks to run inside each deployed image, from the app root:

bundle info activestorage   # expect 8.0.5.2+ or 8.1.4.1+
bundle info mini_magick     # expect 5.1 or later
magick -list policy         # ImageMagick 7
convert -list policy        # ImageMagick 6

Checked against Bundler and ImageMagick documentation; not run against a live app for this article.

Verify and plan ahead

  • Every running image, not just the lockfile, reports the fixed versions.
  • Safe test uploads (images, video, PDF if you use it) still analyze and preview in staging.
  • Rotated secrets are live and old sessions are invalidated.
  • Plan the move off Rails 8.0 before security support ends on November 7. No 7.x release was issued; the latest 7.2 is 7.2.4 from September.

Foire aux questions

What is the CVE for the critical Rails Active Storage flaw?

It has none. It is tracked as GitHub advisory GHSA-f3w6-w445-fwh9.

Is it being exploited?

Neither advisory nor the release post reports exploitation. Don’t confuse it with July’s unrelated libvips issue.

Do I need to rotate secrets if I use S3 storage?

The file-read part of the critical flaw requires the Disk service, so the rotation advice targets Disk-service users. Upgrade regardless.


Sources

Articles connexes sur MAG212 CYBER