CVE-2026-122006

What's affected. From the Rails advisory GHSA-f3w6-w445-fwh9, activestorage before 8.0.5.2, and 8.1 before 8.1.4.1. The fixed releases are 8.0.5.2 and 8.1.4.1. There is no fixed release for Rails 7.x or earlier. The July libvips bug, CVE-2026-66066, did get a 7.2.3.2 fix; this one did not.

The test. Per the Rails advisory, an application is affected only if all three hold: it uses ImageMagick for Active Storage image processing, ImageMagick runs under a policy that does not already deny the coders involved, and it accepts uploads from untrusted users.

1. Check the activestorage version. Run bundle show activestorage or look in Gemfile.lock. Below 8.0.5.2, or 8.1 below 8.1.4.1, is in scope. That includes every Rails 7.x app.
2. Check the variant processor. Search the app for config.active_storage.variant_processor. :mini_magick means ImageMagick. Rails says it is "the default for applications on load_defaults 6.1 or earlier," so an older app that never set it is using ImageMagick. Apps on :vips are outside this advisory.
3. Check who can upload. Any place an untrusted user can attach a file through Active Storage counts, such as avatars, attachments, public forms or APIs that create blobs. Rails says the ImageMagick analyzer "runs when a file is attached."
4. Check the ImageMagick policy on the host. Look at /etc/ImageMagick-6/policy.xml or /etc/ImageMagick-7/policy.xml. Rails says "The policies that Debian and Ubuntu package do not" deny the coders involved, so a stock Debian or Ubuntu server is not protected. Rails also says one attack chain was reported but "we do not assume it is the only one that exists."
5. Check where attachments are stored. Look at config/storage.yml and config.active_storage.service. With the Disk service, Rails says the attacker can also read files the app can read, which decides how much you have to rotate.

Not the same bug as CVE-2026-66066. That July issue was in the libvips path and was fixed in 7.2.3.2, 8.0.5.1 and 8.1.3.1, per NVD. CVE-2026-122006 is the ImageMagick path, with different fixed versions.

Public code. Pruva's reproduction REPRO-2026-00389 verifies the bug against the affected versions. Pruva says its proof reaches code execution because the test app "runs with code reloading enabled (Rails development defaults)," and that the file write and read "are unconditional."

Each of these works only under the condition at the end of its line.

• Delivery. Stop accepting Active Storage uploads from users you don't trust, the third condition in Rails' affected list. This only helps if every upload path untrusted users can reach is closed, including authenticated users you don't trust.
• Exploitation. Copy the rules from the fixed gem's activestorage/lib/active_storage/image_magick/policy.xml into ImageMagick's system policy, the Rails workaround. This only helps if your app has not replaced MiniMagick.cli_env, cleared the environment with MiniMagick.cli_prefix or installed its own MiniMagick::Shell, which Rails says skip the shipped policy. It is also the only option today for Rails 7.x apps.
• Exploitation. Switch variant_processor to :vips, which takes the app out of Rails' affected list. This only helps if the app already has the fix for the libvips bug CVE-2026-66066 (7.2.3.2, 8.0.5.1 or 8.1.3.1), and after you test that images still process the way you need.
• Execution. Run production with eager loading and without write access to the app's own code. Per Pruva, that removes the path its proof used to turn a file write into code execution. This only limits the code-execution step; Pruva says the file write and read still work.
• Blast radius. If attachments use the Disk service, Rails says to change secret_key_base and every secret the app process can read, including the master key, everything in config/credentials.yml.enc, storage and database credentials and third-party tokens, and "Do not retain an exposed secret as a fallback." This only helps after the upload path is closed, or the new secrets can be read the same way.

Upgrading activestorage to 8.1.4.1 or 8.0.5.2, with mini_magick 5.1 or later if you stay on :mini_magick, is the only fix. Rails says an app on an older mini_magick "raises an exception during boot," and an app that renders PostScript or PDF through ImageMagick must re-allow the gs delegate and its coders in the host policy.

Rails has published no indicators for CVE-2026-122006, and no source has published a log signature for the upload step. Patching does not undo a file write or a secret read that already happened. If attachments use the Disk service, follow Rails' rotation guidance above.

Am I exposed to CVE-2026-122006?

Yes, if activestorage is below 8.0.5.2 or 8.1.4.1, the app uses :mini_magick (the default for load_defaults 6.1 or earlier), the host's ImageMagick policy doesn't deny the coders involved, and untrusted users can upload files.

Is CVE-2026-122006 being exploited?

No exploitation has been reported, and it is not on CISA KEV as of November 5, 2026. Pruva has published a working reproduction.

Is there a patch for Rails 7?

No. Fixes exist only for activestorage 8.0.5.2 and 8.1.4.1. On Rails 7.x, upgrade to 8.0.5.2 or later, or copy Rails' ImageMagick policy into the host's system policy.

Is this the same as CVE-2026-66066?

No. CVE-2026-66066 was the July libvips bug. CVE-2026-122006 is the ImageMagick path, with different fixed versions.

How do I mitigate CVE-2026-122006 without patching?

Apply Rails' ImageMagick policy to the host and stop untrusted uploads. These reduce exposure but are not a fix.

Nov 5, 2026. First published. Public reproduction from Pruva; no exploitation reported; not on CISA KEV.

• Rails advisory GHSA-f3w6-w445-fwh9
• NIST NVD: CVE-2026-122006 (MITRE's CNA record; checked Nov 5) and CVE-2026-66066
• Rails 8.1.4.1 release and 8.0.5.2 release
• Pruva reproduction REPRO-2026-00389 (read only, not run)
• CISA Known Exploited Vulnerabilities catalog (checked Nov 5)