Is your Rails app exposed to the Active Storage flaw GHSA-f3w6-w445-fwh9?
GHSA-f3w6-w445-fwh9 lets an attacker with no login upload a crafted file that makes ImageMagick write files on your server, and with the Disk service read files such as secret_key_base. Rails rates it Critical, CVSS 3.0 9.8. Apps using ImageMagick that accept untrusted uploads are exposed. Upgrade Active Storage to 8.1.4.1 or 8.0.5.2.
No CVE yet, not in CISA KEV
The flaw has no CVE yet and is not in CISA's Known Exploited Vulnerabilities catalogue (checked 4 November 2026). The Rails advisory does not say whether it has been exploited. It needs no login, so do not wait: upgrade or apply the interim ImageMagick policy now.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 4 November 2026, 12:29 GMT.
At a Glance
Based on the Rails advisories and CISA as of 4 November 2026. Last updated 4 November 2026, 12:29 GMT.
Critical, CVSS 3.0 9.8
Rated by Rails (CVSS 3.0). No CVE has been assigned yet.
Not in KEV
The advisory does not say whether it has been exploited.
ImageMagick plus uploads
Apps on :mini_magick, with a permissive ImageMagick policy, that accept untrusted uploads.
8.1.4.1 or 8.0.5.2
The fixed releases ship a restrictive ImageMagick policy and fix 21 security issues.
Rails publishes GHSA-f3w6-w445-fwh9 and releases Active Storage 8.1.4.1 and 8.0.5.2.
The same releases fix GHSA-v924-7rp8-4mxh (High, CVSS 8.8, needs a low-privilege login) and 19 other issues.
The flaw is reported publicly. No CVE yet, not in CISA KEV.
Rails 8.0 security support ends. Rails before 8.0 is already unsupported.
Affected and fixed versions
| Version | Status | Fix |
|---|---|---|
| Active Storage 8.1.0 to 8.1.4.0 | Affected | Upgrade to 8.1.4.1 |
| Active Storage 8.0.x below 8.0.5.2 | Affected | Upgrade to 8.0.5.2. Rails 8.0 security support ends on 7 November 2026, so plan the move to 8.1. |
| Rails 7.2 and earlier | Unsupported, no fix released | Upgrade to 8.0.5.2 or 8.1.4.1. Until then, apply the ImageMagick policy below or switch to :vips. |
| Active Storage 8.1.4.1 or 8.0.5.2 and later | Fixed | Check mini_magick is 5.1 or later, or the app fails to boot. |
Are you exposed? All three must be true
- ImageMagick: the app uses
config.active_storage.variant_processor = :mini_magick. This is the default for apps onload_defaults 6.1or earlier. - Permissive policy: ImageMagick's security policy does not block the coders involved. The policies Debian and Ubuntu package do not.
- Untrusted uploads: the app accepts file uploads from users you do not fully trust, such as public sign-up, customers or suppliers.
Attaching the upload is enough. The ImageMagick analyzer runs on attach, so no variant, preview or analyze call is needed. With the Disk service an attacker may also read files the app can read, including secret_key_base and config/credentials.yml.enc, which may in turn allow remote code execution or lateral movement.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Upgrade and restrict
- Inventory every Rails app and check its Active Storage version, variant_processor and load_defaults.
- Upgrade apps that accept uploads first, to 8.1.4.1 or 8.0.5.2.
- Until then, copy the Rails ImageMagick policy into policy.xml, or on Rails 7.0+ switch to :vips.
- Plan upgrades for anything on Rails before 8.0.
Hunt and contain
- Look for unexpected files outside storage directories: web shells, cron jobs, SSH keys, code changes.
- Look for SVG or odd-format blobs from untrusted users.
- Check for ImageMagick processes touching unusual paths.
- If you suspect compromise, rotate secret_key_base, credentials and downstream secrets, and end sessions.
Proactive: Check Exposure and Upgrade
Upgrade the apps that accept uploads first. Until you can, stop ImageMagick running the dangerous coders.
Inventory every Rails app
List every Rails app you run or host for clients, including internal tools and staging. For each, record the Active Storage version, variant_processor, load_defaults and whether it accepts uploads from untrusted users.
# Active Storage and mini_magick versions
bundle exec gem list activestorage mini_magick
# Which image processor and defaults the app uses
grep -rn "variant_processor\|load_defaults" config/
# Does ImageMagick block MSL? (no output means it does not)
magick -list policy | grep -i mslUpgrade upload-accepting apps first
Upgrade Active Storage to 8.1.4.1 or 8.0.5.2, starting with apps that accept public or customer uploads. Make sure mini_magick is 5.1 or later, or the app will fail to boot. If the app renders PDF or PostScript through ImageMagick, re-allow those coders in the host policy. See the Rails advisory.
Interim: block the dangerous coders
If you cannot upgrade today, add rules to ImageMagick's system policy.xml (for example /etc/ImageMagick-7/policy.xml) that copy the policy Rails ships in activestorage/lib/active_storage/image_magick/policy.xml. At a minimum Rails says to deny MSL, the Ghostscript coders and the gs delegate. The block below is the full shipped list. GraphicsMagick ignores ImageMagick policies, and apps that replace MiniMagick.cli_env, cli_prefix or MiniMagick::Shell do not get the shipped policy even after upgrading.
<policymap>
<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="coder" rights="none"
pattern="{EPHEMERAL,TEXT,MPC,SHOW,WIN,PLT,URL,HTTP,HTTPS,FTP,FILE}"/>
<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}"/>
<policy domain="path" rights="none" pattern="@*"/>
</policymap>Or switch to :vips (Rails 7.0 and later only)
On Active Storage 7.0 and later, setting config.active_storage.variant_processor = :vips takes ImageMagick out of the path. It does not help on 6.x, where the image analyser always uses MiniMagick, and it does not fix GHSA-v924-7rp8-4mxh. Test image handling first.
Plan upgrades off Rails before 8.0
Rails before 8.0 is out of support and gets no fix. Rails 8.0 security support ends on 7 November 2026, so plan the move to 8.1. See the Rails maintenance policy.
Check the policy, and rotate Disk secrets
After upgrading or changing the policy, run magick -list policy (or convert -list policy on ImageMagick 6) as the app user and confirm MSL and the other coders are denied. If an exposed app stores attachments with the Disk service, rotate secret_key_base, the master key and every credential, as Rails advises, even without signs of compromise.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams and MSPs. Check each app's exposure offline and hunt for signs of exploitation. Everything is read-only.
check-rails-activestorage.sh
Reads Gemfile.lock, config/application.rb, the environment and initializer files and, optionally, the ImageMagick policy.xml and the storage directory, then reports whether the app is exposed. It lists which of the three conditions hold.
bash check-rails-activestorage.sh --app /srv/myapp \
--policy /etc/ImageMagick-6/policy.xml \
--storage /srv/myapp/storage
# Whole estate (host,activestorage_version,variant_processor,policy)
bash check-rails-activestorage.sh --csv inventory.csvCheck-RailsActiveStorage.ps1
The same checks in PowerShell 7, with the same output and exit codes. It also runs under PowerShell on Linux.
pwsh -File Check-RailsActiveStorage.ps1 -App /srv/myapp `
-Policy /etc/ImageMagick-7/policy.xmlKQL and Sigma
7 KQL queries for Microsoft Sentinel and Defender XDR: ImageMagick started by Ruby, writes outside storage, writes to sensitive paths, shells, access to Rails secrets, SVG, MSL or MVG files in storage, and a vulnerable-version inventory. 5 Linux Sigma rules cover the same ground for other SIEM platforms, with Kusto conversions included.
Verdicts
- PATCHEDActive Storage 8.1.4.1 or 8.0.5.2 or later. Warns if mini_magick is below 5.1.
- LIKELY VULNERABLEAn affected version with ImageMagick in use. Whether uploads are untrusted cannot be checked offline, so confirm it yourself.
- UNKNOWNA missing Gemfile.lock or application.rb, a pre-release version, an unknown processor or a bad CSV.
- NOT EXPOSED:vips on Active Storage 7.0 or later, no mini_magick, no Active Storage, or a policy that blocks the coders. Upgrade anyway.
Exit codes
| Code | Meaning |
|---|---|
| 0 | PATCHED |
| 1 | LIKELY VULNERABLE |
| 2 | UNKNOWN |
| 3 | NOT EXPOSED |
| 5 | Error, such as bad usage or an unreadable file |
MSPs can use the exit code in RMM or scheduled jobs to flag apps at scale. With a CSV, the exit code is the worst row. Rails below 8.0 is flagged EOL.
Know the limits
- Both checkers are read-only and offline. They only read the files you point them at, send no network traffic, write nothing and contain no exploit payloads.
- No indicators of compromise have been published, and the pack contains none. The hunts look for behaviour.
- The hunt paths are unverified. The process tree, the ImageMagick binary MiniMagick calls on your build and the file-write targets (cron, SSH keys, app code, web root) are likely, not confirmed.
- None of the KQL has been run against a live tenant. Fields and paths marked UNVERIFIED depend on your connectors. Endpoint tools rarely log file reads on Linux, so use auditd for secret access.
- Prefer the hand-written KQL. Some Sigma pipeline conversions map these Linux rules to the wrong tables, as the README explains.
What is in the pack
| File | What it does |
|---|---|
| check-rails-activestorage.sh | Offline exposure checker for Linux and macOS (bash) |
| Check-RailsActiveStorage.ps1 | The same checker in PowerShell 7 |
| KQL (7 queries) | Microsoft Sentinel and Defender XDR hunts Q1 to Q7 |
| Sigma (5 rules) | Linux process, file and file-access rules, plus Kusto conversions |
| tests/ | Fixtures, bash and Pester tests and a sandboxed no-network run |
| README.md | Verified facts, corrections, limits and usage |
Reactive: How to Hunt
No indicators of compromise have been published, so hunt for behaviour across the whole period each app ran an affected version. CybaOps can run these hunts across your estate or your clients'.
Unexpected files outside storage directories
Look for new or changed files outside the Active Storage directories: web shells in public/, cron entries, new SSH keys in authorized_keys and changes to app code or config (KQL Q2 and Q3). These paths are likely targets, not confirmed ones.
SVG and odd-format uploads
Review recent blobs from untrusted users for SVG, MVG, MSL or other formats your app does not expect, especially where the content type does not match the extension (checker --storage, KQL Q6). A plain SVG is not proof of an attack.
ImageMagick touching unusual paths
In endpoint or process telemetry, look for magick, convert or identify started by the app writing or reading outside temp and storage paths, or spawning shells (KQL Q1 to Q5 and the Sigma rules). Endpoint tools rarely log file reads on Linux, so use auditd for reads of config/master.key.
Signs of secret use elsewhere
If the Disk service is used, check database, storage and third-party service logs for access from unusual IPs, and app logs for forged sessions or signed cookies.
If you suspect compromise
- Isolate the host and keep its logs, disk and storage directory for investigation.
- Rotate
secret_key_base, the master key and everything inconfig/credentials.yml.enc, plus storage, database and third-party credentials. Do not keep an exposed secret as a fallback. - End all user sessions, as rotating
secret_key_baseinvalidates signed cookies. - Check logs for lateral movement into the systems those secrets reach.
- Upgrade, rebuild from a known good state where you can, and keep monitoring.
Patched does not mean clean
Upgrading stops new attacks but does not remove files an attacker wrote or secrets they read. Every exposed app should be hunted, not just upgraded.
Rails Active Storage GHSA-f3w6-w445-fwh9 FAQ
Short answers based on the Rails advisories and CISA as of 4 November 2026.
What is GHSA-f3w6-w445-fwh9?
It is a flaw in Ruby on Rails Active Storage image analysis. Active Storage did not limit which ImageMagick coders could run, so a crafted upload, such as an SVG that reaches the MSL scripting coder, can make ImageMagick write arbitrary files on the server. With the Disk storage service it can also read files the app can read.
Does it have a CVE?
Not yet. Rails published it as GitHub advisory GHSA-f3w6-w445-fwh9 on 4 November 2026 and rates it Critical, CVSS 3.0 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Track it by the advisory ID until a CVE is assigned.
Is it being exploited or in CISA KEV?
The Rails advisory does not say whether it has been exploited, and it was not in CISA's Known Exploited Vulnerabilities catalogue when we checked on 4 November 2026. Rails says one attack chain was reported to it but it does not assume it is the only one. Treat exposed apps as urgent.
Is my app affected?
Only if all three are true: it uses ImageMagick for Active Storage (variant_processor :mini_magick, the default for apps on load_defaults 6.1 or earlier), its ImageMagick policy does not block the coders involved (the Debian and Ubuntu packaged policies do not), and it accepts file uploads from untrusted users.
Do we need to generate a variant or preview to be at risk?
No. The ImageMagick analyzer runs when a file is attached, so attaching an uploaded file is enough. No variant, preview or analyze call is needed.
How bad is it if we use the Disk service?
Worse. With Disk storage an attacker may also read files the app can read, including secret_key_base, the master key and everything in config/credentials.yml.enc. Rails says that may in turn allow remote code execution or lateral movement into your databases, storage and third-party services. If you use Disk and were exposed, rotate secret_key_base, the master key and all credentials.
How do we fix it?
Upgrade Active Storage to 8.1.4.1 or 8.0.5.2. The fixed versions ship a restrictive ImageMagick policy and need mini_magick 5.1 or later. Apps that render PDF or PostScript through ImageMagick must re-allow those coders in the host policy. The same releases fix 21 security issues in total.
What is GHSA-v924-7rp8-4mxh?
A separate Active Storage flaw fixed in the same releases, rated High, CVSS 3.1 8.8. Unlike GHSA-f3w6-w445-fwh9 it needs a low-privilege login. The uploaded file's extension can choose which decoder FFmpeg or ImageMagick uses, which could disclose files or possibly lead to code execution. Switching to :vips does not fix it. Upgrading to 8.1.4.1 or 8.0.5.2 fixes both.
We cannot upgrade today. What can we do?
Copy the policy from the fixed release into ImageMagick's system policy.xml. At a minimum deny the MSL coder, the Ghostscript coders and the gs delegate, and ideally copy the full list Rails ships, which also blocks URL, FILE, TEXT and other coders that read other files. On Rails 7.0 or later you can instead switch Active Storage to :vips. These reduce risk but do not replace the upgrade.
We are on Rails 7 or earlier. Is there a patch?
No. Rails before 8.0 is out of support and gets no fix. Apply the ImageMagick policy now. Switching to :vips only helps on Rails 7.0 to 7.2, because Active Storage 6.x still analyses images with MiniMagick whatever variant_processor says. Plan the upgrade to a supported release. Rails 8.0 security support ends on 7 November 2026, so aim for 8.1.
Protect Your Web Apps, and Your Clients'
CybaOps monitors your servers, endpoints and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- Rails: Possible arbitrary file write and read in Active Storage image analysis (GHSA-f3w6-w445-fwh9)
- Rails: Possible arbitrary file read and remote code execution in Active Storage (GHSA-v924-7rp8-4mxh)
- Rails: Ship an ImageMagick security policy for every MiniMagick process (8.0 fix commit)
- Rails: Maintenance policy
- The Hacker News: Critical Rails flaw lets attackers write server files via crafted ImageMagick uploads
Related threat guides: Magento PolyShell and PHP2Shell. All threat guides.