Ruby and Rails Vulnerabilities in 2026: KindaRails2Shell, CVEs and What to Patch

Ruby's 2026 looks different from Node's or PHP's. There was no flood of core CVEs. Instead there was one critical Rails bug that shipped in the default configuration, a quiet but serious batch of memory-safety fixes in Ruby's regex engine, a long list of Rack fixes, and three separate incidents on RubyGems.org.

This article walks through all of it, in the order a Rails team should care about it. Every version comes from the official Ruby, Rails, Rack or GitHub advisory, linked inline. If you also run Node.js, Bun or PHP, we have written the same roundup for Node.js, Bun and PHP.

What is the most serious Rails vulnerability of 2026?

CVE-2026-66066, nicknamed KindaRails2Shell: an arbitrary file read in Active Storage variant processing. It lets an unauthenticated attacker read files on the server, including the process environment, which usually holds secret_key_base and service credentials. It is rated Critical, CVSS v4.0 9.5, and was published on 29 July 2026 (GHSA-xr9x-r78c-5hrm).

The cause is an insecure default. Active Storage did not disable libvips' "unfuzzed" operations, which libvips itself considers unsafe for untrusted input. A crafted image upload that triggers variant generation could invoke them.

Your application is affected if both of these are true:

• It uses libvips for variants: Active Storage's variant_processor is set to :vips. That has been the default since load_defaults 7.0.
• It accepts image uploads from users you do not trust.

GMO Flatt Security, one of the two teams that reported the bug, adds two details in its write-up:

• Environments built on Debian or Ubuntu, and the Dockerfile that rails new generates, are affected by default.
• Applications configured to process images with ImageMagick are not affected.

The name comes from the researchers at Ethiack, the other reporting team. Their write-up calls it a "rails2shell… kinda", because the chain to a shell needs several preconditions.

What to do about CVE-2026-66066

1. Upgrade Rails to 8.1.3.1, 8.0.5.1 or 7.2.3.2 or later, and make sure libvips is 8.13 or later. Active Storage now raises an error at boot on older libvips.
2. Rotate secrets if the app accepted untrusted uploads before you patched: secret_key_base, the master key and credentials file, storage service keys, database credentials and third-party tokens. The advisory is explicit that a secret read before the patch stays exposed after it.
3. Add defence in depth: set the VIPS_BLOCK_UNTRUSTED environment variable, or call Vips.block_untrusted(true) in an initializer (ruby-vips 2.2.1 or later).
4. On Rails 6.x, Flatt reports that some non-standard Active Storage configurations are affected and that no 6.x fix exists. Upgrading is the only clean answer.

What Ruby core vulnerabilities were fixed in 2026?

The most important are four memory-corruption bugs in Onigmo, Ruby's regular-expression engine, fixed on 23 October 2026 in Ruby 4.0.9, 3.4.12 and 3.3.13. They are CVE-2026-89078 (a double free) and CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 (integer overflows). GitLab assigned the CVE IDs after the bugs turned up in its own product (Ruby advisory).

You are at risk if your application compiles a regular expression from a string an attacker controls: Regexp.new(input), Regexp.union, Regexp.compile, or interpolation such as /#{input}/. Applications that only use regexes their developers wrote are not affected. Search features, filter builders, routing rules and "match this pattern" settings are the usual places to look.

Two warnings from the advisory are worth repeating. Regexp.timeout does not protect against these bugs, because they corrupt memory during compilation rather than run slowly. And limiting the pattern length is unreliable, because some of the bugs trigger with short patterns. Ruby 3.3 is in security-only maintenance, and 3.3.13 is an explicit exception to that policy because of these CVEs.

The rest of Ruby's 2026 advisories:

Sources: the Ruby security page and the individual advisories it links to. The resolv bypass is worth singling out. If you validate outbound hostnames before fetching a user-supplied URL, CVE-2026-80213 is aimed at exactly that check. Net::HTTP and TCPSocket use the operating system's resolver and are not affected; code that uses Resolv directly is.

Which Rack and gem vulnerabilities should Rails teams patch?

Rack had the longest list: two batches in February and April, with several High-severity path and denial-of-service bugs. Most Rails apps get Rack transitively, so check your Gemfile.lock rather than your Gemfile.

Scores are from the GitHub Advisory Database. A few notes:

• rack-session affects apps that use Rack::Session::Cookie directly with secrets:. A standard Rails app uses Rails' own cookie store (CookieStore in Action Dispatch) and is typically not affected. If you are affected, rotate session secrets after upgrading.
• Rails itself shipped a batch of fixes on 23 March 2026 in 7.2.3.1, 8.0.4.1 and 8.1.2.1, mostly Low-severity. They included an Action View XSS (CVE-2026-33168), a number_to_delimited ReDoS (CVE-2026-33169) and several Active Storage disk and proxy issues. The later 66066 releases include them.
• Rack's April batch has more Moderate and High advisories than this table shows; upgrading to rack 3.2.6, 3.1.21 or 2.2.23 or later covers all of them (Rack advisories).

What happened on RubyGems.org in 2026?

Three separate incidents, none of them a bug in Bundler or the gem client.

• The May spam-publishing campaign. New accounts published packages designed to run code on shared Ruby infrastructure and to try to collect other users' API keys. RubyGems.org paused new registrations, reopened them on 16 May, and yanked more than 500 malicious packages. Ruby Central says it found no evidence that the key-harvesting attempts succeeded (RubyGems blog).

• The legacy API key leak (advisory).

  • What leaked: a CDN caching bug could serve one account's legacy API key to another caller for up to an hour.
  • Who was exposed: people who signed in with RubyGems clients older than 3.2.0, which includes the version Apple ships with macOS.
  • Timeline: Truffle Security reported it on 6 July, it was fixed on 9 July, and all legacy keys were revoked on 22 and 23 July.
  • What to do: if you ever used one, audit your gems for versions, owners or trusted publishers you did not add.

• SleeperGem, July 2026. StepSecurity analysed malicious releases of three gems:

  • git_credential_manager 2.8.0 to 2.8.3, impersonating Microsoft's Git Credential Manager;
  • Dendreo 1.1.3 and 1.1.4, from a gem dormant since 2020;
  • fastlane-plugin-run_tests_firebase_testlab 0.3.2.

  The loader skipped CI environments and installed a persistent backdoor via systemd and cron on developer machines.

RubyGems.org responded with guidance to wait a few days before adopting newly published gem versions, published in June, and security warnings on gem pages, live since 15 October.

Which Ruby and Rails versions are still supported?

Ruby 3.3, 3.4 and 4.0, and Rails 8.0 and 8.1, but Rails 8.0's security support ends on 7 November 2026. Ruby 3.2 reached end-of-life in spring 2026; its last release was 3.2.11 on 27 March. Rails 7.2.4, released on 24 September, was announced as "the last release of the 7.2.x series."

Rails' maintenance policy gives each minor series security fixes for two years after its first release. Ruby dates are from the Ruby branches page. Ruby publishes them as preliminary, so the 3.3 end date is the expected one.

How do you check a Ruby app for vulnerable gems?

Run bundler-audit against your Gemfile.lock in CI, and treat a new advisory as a failing build. It checks every locked gem version against the community ruby-advisory-db:

gem install bundler-audit
bundle-audit check --update   # refresh the advisory database, then check Gemfile.lock

A few habits catch what bundler-audit cannot:

• Check default gems separately. resolv, erb, zlib and json ship with Ruby, so their versions depend on your Ruby patch level unless your Gemfile pins newer ones. gem list resolv erb zlib json shows what is actually installed.
• Rebuild images. A ruby:3.4 base image pulled last month has last month's Ruby. Check ruby -v in the running container.
• Add a cooldown. Review dependency updates that arrive within days of their release, as RubyGems.org now recommends, and be suspicious of dormant gems that suddenly publish.
• Harden your own gems. Use scoped API keys or trusted publishing, and set MFA to ui_and_api on RubyGems.org.

What should you patch first?

1. Rails to 8.1.3.1 or later (or 8.0.5.1), with libvips 8.13 or later, and rotate secrets if you took untrusted image uploads before patching.
2. Ruby to 4.0.9, 3.4.12 or 3.3.13, especially if any code builds a Regexp from user input.
3. Rack to 3.2.6, 3.1.21 or 2.2.23, and rack-session to 2.1.2.
4. Native and web gems: puma, nokogiri, rubyzip, devise and rails-html-sanitizer to the versions in the table above.
5. Plan the upgrade off Rails 8.0 and 7.2, since 8.0 loses security support on 7 November.
6. Add bundle-audit check --update to CI, and replace any legacy RubyGems API keys.

Nordbeam builds and maintains web applications. If your Rails or Ruby version is out of support and the upgrade keeps getting pushed back, our software development team can help you plan it.