Critical Active Storage flaw in Ruby on Rails lets an uploaded file read and wr…

What happened

Ruby on Rails is a popular framework for building web applications in Ruby. It includes Active Storage, the component that handles file uploads such as profile photos, documents and attachments. For images it often relies on the well-known ImageMagick program to read dimensions and other details.

On November 4, 2026, the Rails team published security advisory GHSA-f3w6-w445-fwh9 along with fixed versions 8.1.4.1 and 8.0.5.2. The flaw is tracked as CVE-2026-122006 and listed in the EU vulnerability database EUVD as EUVD-2026-116914. Rails rates it critical: an app may let an attacker with no login write arbitrary files to the server and, under certain conditions, read files the app can access.

The issue was responsibly reported by researcher ryotak through HackerOne. It is not currently in the CISA KEV catalog, and EUVD does not list it as exploited. Rails says one specific attack chain was reported, but it does not assume that is the only one. The same releases also fix several other issues in other parts of Rails.

Why it is dangerous

This is an “insecure default” type of weakness (CWE-1188). Active Storage did not restrict any of ImageMagick’s modules. ImageMagick decides how to handle a file based on its content, and some of its modules work not only on the image itself but also on files the image refers to.

Picture a mailroom clerk who opens every envelope. If one contains a note saying “take folder X from the cabinet and do this with it,” the clerk does it, because nobody said not to. In a similar way, ImageMagick can be steered by an uploaded file into working with files on the server.

The key point is that simply attaching the file is enough. According to Rails, image analysis runs automatically on upload, so the app does not need to resize or otherwise process it. The attack works over the internet through an ordinary upload form. If the app allows uploads without logging in, the attacker needs no account at all.

Rails says an attacker may write files to the server. If the app stores attachments on local disk (the Disk service), the attacker may also read files the app can access. These typically include secret_key_base and credentials for the database or external services. Rails notes this may in turn lead to remote code execution or lateral movement to those systems.

CVSS is a severity scale from 0 to 10. The 9.8 (critical) score comes from MITRE’s CVE record, and the Rails advisory lists the same value. It reflects a network attack, low complexity, no login and no user interaction. The CISA KEV catalog lists flaws that the US agency CISA has confirmed are being exploited. This flaw is not in it yet, which does not mean it won’t be exploited.

Who is affected

The affected package is the activestorage gem, part of Ruby on Rails:

all versions below 8.0.5.2
versions from 8.1 below 8.1.4.1

According to Rails, an app is vulnerable only if all three conditions apply:

it uses ImageMagick for Active Storage image processing, meaning config.active_storage.variant_processor = :mini_magick. This is the default for apps on load_defaults 6.1 or earlier.
ImageMagick runs under a security policy that does not already block the modules involved. The policies shipped by Debian and Ubuntu do not.
the app allows file uploads from untrusted users.

Typical examples are online shops, customer portals, internal systems and SaaS services built on Rails, running on Linux servers or in containers. If an outside company built your app, ask them directly. Apps without Active Storage, apps using an image processor other than :mini_magick, and apps where only trusted people can upload files are not affected.

How to check if you are affected

The commands below only read information and change nothing. Run them in the app directory on the server. Versions of activestorage and mini_magick:

grep -E "activestorage|mini_magick" Gemfile.lock

Which image processor the app actually uses, and its load_defaults:

bundle exec rails runner -e production "p Rails.application.config.active_storage.variant_processor"
grep -n "load_defaults" config/application.rb

Where attachments are stored (look for service: Disk) and which ImageMagick policy is in effect:

grep -rn "active_storage.service" config/environments/
cat config/storage.yml
identify -version
identify -list policy

If activestorage is an affected version, the processor is :mini_magick and the app accepts files from the public, treat it as vulnerable. If production uses the Disk service, the secret rotation described below applies to you too.

How to fix it

The fixed versions are activestorage 8.1.4.1 and 8.0.5.2. They ship an ImageMagick security policy that blocks the dangerous modules and applies to every ImageMagick command run through MiniMagick. The policy adds to the server’s own policy rather than replacing it.

Recommended steps:

Confirm whether you are affected and schedule the upgrade as soon as possible.
Upgrade Rails to 8.1.4.1 (8.1 branch) or 8.0.5.2 (8.0 branch), starting in a test environment.
With the :mini_magick processor you also need mini_magick 5.1 or later. With an older version the app fails at boot.
If your app renders PostScript or PDF through ImageMagick, you must re-allow the gs delegate and the modules you use in the system policy.xml.
If your app replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix or installs its own MiniMagick::Shell, it won’t get the shipped policy, so put the rules in ImageMagick’s system policy. GraphicsMagick does not read ImageMagick policies.
Test image uploads and deploy to production.
If you store attachments with the Disk service, rotate secrets as described below.

If you can’t upgrade right away, Rails recommends copying the rules from activestorage/lib/active_storage/image_magick/policy.xml into ImageMagick’s system policy, for example /etc/ImageMagick-7/policy.xml. At a minimum, block the MSL module, the Ghostscript modules and the gs delegate:

<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}" />

Rails also published standalone patches for those who can’t move to a new release yet: commit 468aa9a for 8.1 and ea8c401 for 8.0. Changing the system policy is only a temporary safeguard and does not replace the upgrade.

What if you may already be compromised

Rails has not published specific indicators of compromise. If your app was vulnerable and accepted files from the public, assume an attacker may have written files to the server. If attachments were stored with the Disk service, secrets may also have leaked.

If you store attachments with the Disk service, Rails recommends rotating secret_key_base and every secret the app can read: the master key, everything in config/credentials.yml.enc, storage and database credentials, and third-party tokens. Do not keep the old key as a fallback.

What to look at:

app and web server logs: an unusual number of uploads, uploads from unknown addresses, or uploads ending in ImageMagick errors
new or modified files in the app directory, temporary directories and Active Storage storage
unknown accounts in the app, new SSH keys or cron jobs
unusual logins to the database, storage and external services the app has access to

If you find anything suspicious, or the app handles sensitive customer data, bring in an incident response specialist. Back up logs before making changes so evidence is preserved. If personal data may have leaked, remember the GDPR breach notification duty.

Sources

Articles are put together by an AI agent from public sources (vendors, CISA, ENISA, NVD, SK-CERT, NÚKIB), and version numbers and CVEs are checked against them automatically. Always confirm the steps in the vendor advisory before touching production.

Critical Active Storage flaw in Ruby on Rails lets an uploaded file read and write server files