Fix CVE-2026-122006 in Rails Active Storage: upgrade and verify ImageMagick policy

Upgrade Rails Active Storage to 8.1.4.1 on the 8.1 branch, or 8.0.5.2 on the 8.0 branch. Ensure MiniMagick is at least 5.1 before restarting an application configured to use it. The fix adds an ImageMagick policy; verifying the installed gem version alone does not establish that image-processing commands receive that policy.

The Rails advisory describes server-side file writes through image analysis and, with the Disk storage service, reads of files accessible to the application. For affected Disk deployments, Rails also calls for replacing the application secret and other readable credentials. Complete the upgrade before putting replacements into service.

Determine whether your upload path is affected

Check the deployed configuration, rather than assuming a recent Rails version uses recent application defaults. The advisory concerns applications that accept untrusted uploads, use ImageMagick through the MiniMagick variant processor, and lack an adequate ImageMagick policy. Applications retaining defaults from Rails 6.1 or earlier can still select MiniMagick.

Attaching a file can trigger the analyzer. Having no thumbnail or explicit analysis call does not remove that path. Using object storage instead of Disk does not, by itself, eliminate the file-write issue.

Inspect the resolved activestorage and mini_magick versions, the effective variant_processor, the selected storage service, and image-processing configuration on both web and job workers. Record custom MiniMagick environment or shell wrappers. The Active Storage guide explains how the policy is supplied to child processes.

Select the fixed release for your branch

The 8.1.4.1 release notes and 8.0.5.2 release notes provide the branch changes. Do not force an isolated Active Storage gem into an incompatible Rails bundle. Update the Rails dependency set together and review the lockfile resolution.

Apply the update without losing normal upload behavior

1. Prepare recovery and contain exposure. Keep a secure backup of application configuration and the database. Inventory credential consumers and recovery access. If the upload path cannot be secured during maintenance, suspend untrusted uploads while preparing the fixed build.
2. Update dependencies in a staging copy. Select the fixed release for your current branch and resolve compatible Rails gems. For MiniMagick deployments, select version 5.1 or later. Confirm the resolved versions in the built artifact, including background-worker images.
3. Review image-policy exceptions before deployment. The new restrictions can affect other uses of MiniMagick within the same application. Inventory PDF, PostScript, and other document conversions alongside ordinary JPEG and PNG transformations.
4. Rebuild and replace every affected process. Deploy web and job workers, drain old instances, and ensure queued work is handled by the patched artifact. Check startup errors before restoring uploads.
5. Verify policy and service behavior. Use the checks below in a disposable environment, then confirm the same artifact and configuration were deployed everywhere. A successful home-page response does not verify attachment analysis.

Handle PDF processing and custom MiniMagick configuration

The shipped policy is added through MiniMagick.cli_env and MAGICK_CONFIGURE_PATH. Inspect the policy from a process launched through the application's MiniMagick integration; a separate terminal process may have a different environment.

The release notes explain that replacing MiniMagick.cli_env after boot, stripping its environment with cli_prefix, or supplying a custom MiniMagick::Shell can bypass this integration. Such deployments need the restrictions in the system ImageMagick policy. GraphicsMagick does not consume ImageMagick policy files.

PDF and PostScript conversions require special review because the fixed policy denies their coders and the Ghostscript delegate. Rails documents re-enabling the specific delegate and coders required by that workflow in the host policy. Treat this as a deliberate exception, restrict it to necessary formats, and verify the resulting effective policy. Do not broadly allow every coder to make a failing preview work.

Rotate secrets for affected Disk deployments

The vendor's rotation guidance covers secret_key_base, the Rails master key and encrypted credentials, storage/database credentials, and third-party tokens readable by the application process.

Use your credential-management procedure to issue replacements, update dependent services, and revoke previous values. Plan for session invalidation and any data encrypted with old keys. Keep recovery material secure, but do not leave a potentially exposed secret accepted as a fallback. Resetting an application password alone does not replace infrastructure credentials.

If suspicious access is found, preserve relevant evidence and follow your incident-response procedure. Installing the fix does not establish whether files were previously accessed.

Verify the fix and ordinary functionality

Use synthetic attachments and test accounts. Keep these checks separate from any production exposure investigation.

• Inspect ImageMagick's effective policy through MiniMagick in the deployed application environment. Confirm the shipped policy directory and restrictions are present, including the MSL coder and gs delegate denials unless a reviewed workflow exception applies.
• Upload and attach a small ordinary PNG and JPEG. Confirm dimensions are recorded, jobs finish, and the expected variants can be retrieved.
• Exercise required PDF/PostScript workflows separately. Verify their narrow policy exceptions and inspect errors rather than disabling the entire policy.
• Check direct uploads, authorized downloads, normal sign-in, and worker queues after deployment and any secret rotation.

ImageMagick's policy documentation describes policy inspection and format restrictions. A policy listing verifies configuration, not every security property of an application.

Temporary mitigation and rollback

If immediate upgrading is impossible, Rails recommends applying the fixed release's complete policy rules to the system ImageMagick policy. Obtain the policy from the pinned fixed source, verify that application processes load it, and retain the upgrade plan. A file-extension filter is not equivalent to the policy.

If the new build breaks a required conversion, keep uploads suspended or constrained while resolving the incompatibility. A rollback to an affected build must retain verified system-policy protection; restoring an old application secret is not a routine recovery step.

Evidence and verification limits

The canonical CVE record was originally published on November 4, 2026, at 14:12:17 UTC. It assigns CVSS 3.1 9.8 from MITRE and links the Rails advisory. The Casco CVE page provides the record overview.

Research date: November 4, 2026 (UTC).

The component checks used the same ImageMagick binary with two policy environments. They did not run vulnerable and fixed Rails applications or invoke MiniMagick, and do not establish that a Rails deployment loads the policy. A full Rails deployment, storage-backend integration, PDF workflow, and credential-rotation procedure were not exercised for this guide. Operators must verify those behaviors against their own deployment. The sanitized evidence records the actual checks and their scope.