Rails releases 8.1.4.1 and 8.0.5.2, patching 21 issues in one of its broadest security batches
Two coordinated security releases landed this morning. Rails published 8.1.4.1 and 8.0.5.2 roughly 16 minutes apart, tagging 8.0.5.2 at 02:30 UTC and 8.1.4.1 at 02:45, then announced both together through the security team.
21 issues spanning nearly every subsystem is more than most single Rails releases touch in an entire year. By most accounts this is one of the broadest batches in recent memory.
At the top of the stack is a Critical flaw in Active Storage. GHSA-f3w6-w445-fwh9 scores 9.8 on CVSS and lets an attacker read and write arbitrary files through ImageMagick-based image analysis. A crafted upload can reach coders that act on files named inside the image instead of the image itself, and Active Storage didn't constrain any of them.
Read the process's files and secret_key_base, credentials, and database credentials usually follow. That path tends to end at remote code execution, which is exactly why this issue should make you move fast.
The full tally is one Critical, four High, 13 Medium, and three Low.
The part worth actually worrying about
Three more Highs round out the serious ones. There's a second RCE in video and image processing (GHSA-v924, 8.8) rooted in how Active Storage names tempfiles from uploaded filenames. Another opens a Strong Parameters bypass in Parameters#each_key (GHSA-wm3x, 7.5) so an attacker can set unpermitted attributes, like an authorization flag, the kind of thing you really don't want a logged-in user handing to themselves.
A DoS in safe_constantize makes the fourth High. Reachable through Action Cable (GHSA-8474, 7.5), it happens because an unescaped constant name gets interpolated into a regex. Not a tidy way to hang a server.
Most of the batch sits in the Medium and Low range. A cluster of XSS flaws hits Action View's text helpers, strip_tags, highlight, the tag helpers, plus one XSS in the Active Support MessagePack serializer, also 8.1-only. Cookie and session handling, cache poisoning, cloud-storage signing gaps, and a Mailgun signature-replay quirk make up the rest.
The real story here isn't the vulnerabilities though. It's the calendar.
Security support for the 8.0 series ends on 7 November 2026. That's three days after these releases went out. The announcement makes the stakes explicit: a further 8.0 security patch would only show up if a new flaw were disclosed and fixed before that date. Otherwise 8.0.5.2 is very likely the final security release for the entire 8.0 line.
If your production apps are still on 8.0, you now have a hard deadline instead of a gentle nudge. Going from 8.0.5.x to 8.0.5.2 is a minimal bump since security releases stack on top of the last regular release, so the immediate hole closes quickly. That buys nothing past November 7th. The actual fix is migrating to 8.1.4.1.
Here's a detail that trips people up. Rails uses a shifted version of semver, and the fourth digit marks a security release, so 8.1.4.1 is the first security patch on the 8-1-stable branch layered over the regular 8.1.4. npm can't use a fourth digit, which is why gem 7.0.1.4 becomes npm 7.0.104. Someone thought that mapping made sense once. Don't ask me who.
Mike Dalessio, who goes by flavorjones, posted the releases on both the rubyonrails-security mailing list and the Rails blog. He's maintained Rails' HTML sanitization stack for years, keeping loofah and rails-html-sanitizer, which makes it fitting that a batch dominated by XSS and sanitization opens with him. He joined the Rails Core team in September 2026 after gaining Committer rights in May.
One pattern worth flagging. A large share of the Medium and Low findings came from the Anthropic OSS Scanner, carrying ANT-2026-* identifiers, rather than from human reporters on HackerOne. That's increasingly the norm for under-resourced open-source projects. Automated tools catching what a small team can't. Not bad news, just how this stuff gets fixed now.
Most advisories here say "No known CVE" and lean on GitHub Advisory Database IDs instead. Reference the GHSA IDs when you verify or patch, since not every one carries a CVE yet. Two do tie back to older ones: the Strong Parameters bypass is an incomplete fix of CVE-2020-8164, and the session-cookie leak runs around the CVE-2024-26144 fix.
If you can't patch right now
Not everyone can restart mid-week. A few issues have workarounds while you line up a maintenance window.
For the ImageMagick RCE, upgrade mini_magick to 5.1 or newer, ship a hardened policy.xml, or disable ImageMagick variant processing plus the video and preview analyzers until you're patched. The Strong Parameters bypass stays avoided as long as you never feed Parameters#each_key's return value into mass assignment. The 8.1 IP-spoofing gap can be worked around by setting Rack::Request.forwarded_priority to [:x_forwarded] in an initializer. GCS direct-upload teams must add the x-goog-content-length-range header to their bucket's CORS responseHeader list or uploads will break after the upgrade.
Release 8.1.4.1 · rails/rails
Active Support ActiveSupport::MessagePack no longer deserializes an unsafe ActiveSupport::SafeBuffer as html_safe. A SafeBuffer that was no longer html_safe?, for example after an in-place gsub!,...
Release 8.0.5.2 · rails/rails
Active Support ActiveSupport::Inflector#safe_constantize matches the constant name in a LoadError message as a literal string instead of building a Regexp from it. The name's segments were interp...
