Rails 8.1.4.1 Security Release: 21 Fixes and How to Upgrade

Updated 10 November 2026. Rails 8.0 reached the end of security support on 7 November, three days after the 8.1.4.1 and 8.0.5.2 security releases, so 8.0 apps should now plan the move to 8.1.

Rails 8.1.4.1 and 8.0.5.2, released on 4 November 2026, fix 21 security issues across Active Storage, Action Pack, Action View, Active Support and other Rails gems. The most serious is a critical Active Storage flaw, CVSS 9.8, that can let an unauthenticated user write files on the server just by uploading a crafted file, if your app processes attachments with ImageMagick. The Rails team strongly recommends upgrading as soon as possible.

Upgrade to 8.1.4.1 if you are on Rails 8.1. If you are on 8.0, version 8.0.5.2 closes the issues that affect 8.0, but the 8.0 series stopped getting security fixes on 7 November 2026, so treat it as a stopgap. Rails 7.2 and older got no release at all. This guide covers what changed, how to tell whether the critical bug affects you, and the upgrade steps.

Related: Google Play Japan Authorization by Dec 1, Trader Status by Feb 1

Rails 8.1.4.1 at a glance

What does Rails 8.1.4.1 fix?

The announcement lists 21 GitHub security advisories. These are the critical and high ones:

The 13 medium issues include four cross-site scripting bugs in Action View helpers (text helpers, highlight, strip_tags and tag helpers), an XSS in the MessagePack serializer on 8.1, a denial of service in Action Controller streaming, two more in Active Storage, two Google Cloud Storage direct upload bugs, restorable destroyed sessions in the cache store, a session cookie leak in Active Storage proxy mode and cache poisoning through content negotiation. The three low ones cover local file disclosure in video previews, signature replay in Action Mailbox's Mailgun ingress and session cookies without the SameSite attribute.

Is my app affected by the critical Active Storage bug?

GHSA-f3w6-w445-fwh9, also published as CVE-2026-122006, affects apps where all three of these are true, according to the advisory:

1. Active Storage processes images with ImageMagick through MiniMagick, which means config.active_storage.variant_processor is :mini_magick. That is the default for apps with config.load_defaults 6.1 or older; load_defaults 7.0 and newer switch to :vips.
2. ImageMagick runs with a security policy that does not already deny the dangerous coders. The advisory says the default policies on Debian and Ubuntu do not.
3. The app accepts uploads from untrusted users.

The ImageMagick analyzer runs when a file is attached, so no variant, preview or analyze call is needed. If attachments use the Disk service, the attacker may also read files the app can read, typically including secret_key_base and other credentials, which can lead to remote code execution. Two quick checks, run from your app directory and on the server:

# Which variant processor is the app actually using?
bin/rails runner 'p ActiveStorage.variant_processor'

# Which ImageMagick policy is active? (ImageMagick 7)
magick identify -list policy

If the first command prints :mini_magick, treat the app as affected until it runs 8.1.4.1 or 8.0.5.2. Apps on :vips avoid this specific bug, but they can still be exposed to the video issue below if they analyze video or audio uploads.

What are the other high-severity fixes?

Video previews and analysis (GHSA-v924-7rp8-4mxh)

Active Storage wrote uploads to temporary files that kept the uploaded extension, and tools such as FFmpeg and ImageMagick pick a decoder from that extension. With an FFmpeg build that has AviSynth enabled, a .avs file could be run as a script. The advisory notes that upstream FFmpeg and common Linux and Homebrew packages do not enable AviSynth, but the GPL Windows and Linux builds from ffmpeg.org do. If you cannot upgrade yet, remove ActiveStorage::Previewer::VideoPreviewer from config.active_storage.previewers, and the VideoAnalyzer and AudioAnalyzer from config.active_storage.analyzers.

Strong Parameters bypass (GHSA-wm3x-v3qw-4jh3)

Calling each_key on params with a block returned the raw hash instead of the Parameters object, so passing that return value into new, update or assign_attributes skipped the permit check. Rails itself never does this, so you are only exposed if your own code passes the result of each_key into mass assignment. A quick search tells you:

grep -rn "each_key" app/ lib/

Forwarded header IP spoofing (GHSA-2gff-2mmg-m73p)

Since 8.1.0, request.remote_ip comes from Rack's forwarded_for, which under Rack 3 prefers the Forwarded header. If your proxy appends to X-Forwarded-For but passes a client-supplied Forwarded header through, a client can choose its own IP, which can bypass IP allow lists and the default key of rate_limit. After the upgrade, Rails raises ActionDispatch::RemoteIp::IpSpoofAttackError when the two headers disagree, so watch your error tracker, and configure the proxy to strip or overwrite Forwarded. The advisory's stopgap for proxies that set X-Forwarded-For, which needs Rack 3.0 or later:

# config/initializers/forwarded_priority.rb
Rack::Request.forwarded_priority = [:x_forwarded]

With that setting, Rack also stops using Forwarded for the request scheme, host and port.

Should I also update trilogy?

Yes, if your app talks to MySQL through Trilogy. On 29 October 2026 the Rails security list published GHSA-744p-w4gc-m3gh, a critical SQL injection (CVSS 4.0 score 9.3) in Trilogy#escape. Versions 2.13.1 and earlier are affected, and 2.13.2 is patched. The advisory says apps can be exposed even on the default utf8mb4 charset when an attacker can influence the encoding of a string the app escapes. Connections set to sjis, cp932, big5, gbk or gb18030 now raise ArgumentError.

How to upgrade to Rails 8.1.4.1: 8 steps

1. Check what you run.

   bin/rails --version
   bundle info activestorage
   bundle info mini_magick
   bundle info trilogy

2. Raise the minimum version in your Gemfile, then run bundle update rails and review the Gemfile.lock diff:

   # Rails 8.1 apps
   gem "rails", "~> 8.1.4", ">= 8.1.4.1"
   
   # Rails 8.0 apps, as a stopgap until you move to 8.1
   gem "rails", "~> 8.0.5", ">= 8.0.5.2"

3. Update mini_magick if you use it. The fix needs mini_magick 5.1 or later with the :mini_magick processor, and older versions raise an exception at boot. The Active Storage engine itself suggests gem "mini_magick", "~> 5.1".
4. Update trilogy to 2.13.2 or later with bundle update trilogy, if it is in your bundle.
5. Re-check PDF and PostScript handling. The fixed versions ship an ImageMagick policy that denies, among others, Ghostscript-backed coders and the gs delegate. If your app renders PDF or PostScript through ImageMagick, re-allow only what you need in the host policy.xml. Apps that replace MiniMagick.cli_env after boot, clear the environment with MiniMagick.cli_prefix or use a custom MiniMagick::Shell do not get the shipped policy and must put equivalent rules in the system policy.
6. Test, then deploy everywhere. Restart web processes and background job workers too, because Active Storage analysis can run in background jobs.
7. Rotate secrets if you were exposed. If the app used ImageMagick with the Disk service and accepted untrusted uploads, the advisory says to rotate secret_key_base and every secret the process can read: the master key, the contents of credentials.yml.enc, storage and database credentials and third-party tokens. Rotating secret_key_base ends active sessions and invalidates signed or encrypted cookies and Active Storage URLs, so plan a quiet window, and do not keep exposed secrets as fallbacks.
8. Plan the 8.0 to 8.1 move if you are on 8.0, as described below.

Like the Node.js security release and the WordPress 7.1.4 release we covered last month, this one is routine work that only pays off if every app actually gets it. File upload bugs are a favorite attack path, as the Magento PolyShell case showed, so upload handling deserves a place in your web application security checklist.

Is Rails 8.0 still supported?

Not for new security fixes. Under the Rails maintenance policy, each minor series gets security fixes for two years after its first release. As of 10 November 2026, the maintenance page lists 8.1.x as supported for security issues until 10 October 2027 and 8.0.x until 7 November 2026, which has now passed. Future security releases will not include an 8.0 version.

The official upgrade guide keeps the 8.0 to 8.1 step small. Rails 8.1 needs Ruby 3.2.0 or newer, the same as 8.0:

# 1. In the Gemfile: gem "rails", "~> 8.1.4", ">= 8.1.4.1"
bundle update rails

# 2. Review each generated change interactively
bin/rails app:update

# 3. Run your test suite (bin/rails test or bundle exec rspec)

The update task creates config/initializers/new_framework_defaults_8_1.rb. Turn its settings on gradually across deploys, then delete the file and set config.load_defaults 8.1 in config/application.rb. The only 8.0 to 8.1 note in the guide is that schema.rb now lists table columns alphabetically, which gives you one noisy diff the first time you dump the schema.

Still on Rails 7.2 or older?

You got no release on 4 November. The announcement says older versions are unsupported, and RubyGems shows 7.2.4, from 24 September 2026, as the last 7.2 release as of 10 November 2026. The advisories list every version before 8.0.5.2 as affected, so a 7.2 app that uses ImageMagick and takes public uploads carries the critical bug. Stopgaps while you plan the upgrade:

• copy the rules from activestorage/lib/active_storage/image_magick/policy.xml into the system ImageMagick policy or, at minimum, deny the MSL coder, the gs delegate and the Ghostscript-backed coders, as the advisory describes;
• remove the video previewer and the video and audio analyzers if you do not need them;
• keep untrusted uploads away from older apps until they are upgraded.

The Rails guide recommends moving one minor version at a time, so 7.2 goes to 8.0 and then to 8.1. If the app is far enough behind that this feels like a rebuild, our guide on when to rewrite or refactor can help you decide, and our app maintenance cost guide shows how to budget for keeping up.

If you run a Rails app that has fallen a few versions behind, or you want someone to check your Active Storage and proxy setup, our web development team can help. Get in touch with your Rails and Ruby versions.

Rails 8.1.4.1 FAQ

Does the Active Storage vulnerability affect apps that use vips?

Not the critical one. GHSA-f3w6-w445-fwh9 needs ImageMagick through MiniMagick, and apps on load_defaults 7.0 or newer use :vips unless they changed it. Apps on vips can still be exposed to GHSA-v924-7rp8-4mxh if they analyze or preview video and audio uploads with FFmpeg, and to the other fixes in the release. Upgrade either way, because the release covers 21 issues, not one.

Is CVE-2026-122006 the same as GHSA-f3w6-w445-fwh9?

Yes. The CVE record, published on 4 November 2026, describes the same Active Storage flaw: when ImageMagick attachment processing runs, a crafted file can trigger server reads and writes, such as reading secret_key_base, because no ImageMagick security policy blocked the dangerous features. Both carry a CVSS score of 9.8. The GitHub advisory had not yet listed the CVE when we read it.

Does upgrading to Rails 8.1.4.1 break anything?

The announcement lists no breaking changes, but three side effects are worth testing. The new ImageMagick policy blocks PDF and PostScript work through Ghostscript unless you re-allow it. The :mini_magick processor now needs mini_magick 5.1 or later and fails at boot without it. Behind proxies that report the client differently in Forwarded and X-Forwarded-For, Rails now raises IpSpoofAttackError.

Is the Rails Active Storage bug being exploited?

Neither the Rails announcement nor the advisories we read report exploitation, as of 10 November 2026. The critical advisory says one attack chain was reported through HackerOne and that other chains may exist. Because the bug needs only an upload and no login, and the patch commits are public, assume someone is working on it and upgrade now instead of waiting for reports.

Do I need to rotate secret_key_base after upgrading?

Only if you were exposed. The advisory asks apps that used ImageMagick with the Disk service and accepted untrusted uploads to rotate secret_key_base and every secret the process could read. The video advisory asks the same of apps with an AviSynth-enabled FFmpeg. Rotation logs everyone out and invalidates signed cookies and Active Storage URLs, so schedule it.

How long is Rails 8.1 supported?

As of 10 November 2026, the Rails maintenance page lists security fixes for the 8.1 series until 10 October 2027. The policy gives each minor series two years of security fixes from its first release, so moving from 8.0 to 8.1 now buys you about eleven months before the next required upgrade, assuming the dates on the maintenance page do not change.

Sources

• Ruby on Rails: Rails 8.0.5.2 and 8.1.4.1 have been released (4 November 2026)
• GitHub advisory GHSA-f3w6-w445-fwh9: arbitrary file write and read in Active Storage image analysis
• GitHub advisory GHSA-v924-7rp8-4mxh: file read and code execution in Active Storage video previews and processing
• GitHub advisory GHSA-wm3x-v3qw-4jh3: Strong Parameters bypass in Parameters#each_key
• GitHub advisory GHSA-2gff-2mmg-m73p: IP spoofing in Action Dispatch RemoteIp
• CVE record: CVE-2026-122006
• GitHub advisory GHSA-744p-w4gc-m3gh: SQL injection through Trilogy#escape (29 October 2026)
• Rails security announcements: Trilogy#escape SQL injection
• Ruby on Rails: maintenance policy and supported versions
• Rails Guides: Upgrading Ruby on Rails
• Rails source, v8.1.4.1: Active Storage engine
• RubyGems: rails versions
• ImageMagick: security policy