Security updates for Ruby and Rails: which versions are still patched, and a routine that keeps you on them

On 7 November 2026 Rails 8.0 stopped receiving security fixes. Three days earlier, the 4 November security release fixed 21 issues in Rails, and it was the last one 8.0 will get. If your application runs on Rails 8.0 or older, the next Rails vulnerability will not be fixed for you.

That is the part of keeping a Rails application healthy that nobody schedules: not the big upgrade, but the small, frequent security releases, and knowing when your version has fallen off the end of the list. This is how it works today and the routine we use for our own production application and for clients.

Which versions still get security fixes

Rails. Rails works to a fixed calendar: each minor series gets bug fixes for one year after its first release and security fixes for two years. As of 13 November 2026, from the Rails maintenance page:

Rails	Bug fixes until	Security fixes until
8.1	10 October 2026	10 October 2027
8.0	ended	ended 7 November 2026
7.2 and older	ended	ended (7.2's last release was 7.2.4, September 2026)

So today exactly one series, 8.1, gets security fixes. The latest release is Rails 8.1.4.1, from 4 November.

Ruby. A new Ruby comes out every 25 December. From the Ruby branches page:

Ruby	Status	End of life
4.0	normal maintenance (bug and security fixes)	not announced
3.4	normal maintenance	not announced
3.3	security maintenance only	end of March 2027
3.2 and older	end of life	3.2 ended 1 April 2026

The latest patch releases, all from 23 October 2026, are 4.0.9, 3.4.12 and 3.3.13. In recent years a branch has had a little over three years of normal maintenance followed by one year of security-only fixes, so Ruby 3.3 has about four months left.

An application on Rails 8.0 with Ruby 3.3 is fine for a few months, but it is already one version behind on Rails and close to the end on Ruby.

Where the announcements come from

You do not need to read every changelog, but someone should see these:

• Ruby: security advisories are posted as news on ruby-lang.org, with an RSS feed. Many are not in Ruby itself but in a gem that ships with it. In August 2026 two CVEs in the bundled resolv gem were fixed by updating that gem (to 0.7.2), not by waiting for a new Ruby.
• Rails: the Rails Security Announcements forum gets each announcement the moment the embargo lifts, the security mailing list gets a copy, and every fix is filed as a GitHub security advisory. Each advisory links to patches you can apply if you cannot upgrade the same day.
• Every other gem: the Ruby Advisory Database, which bundler-audit reads. Since October 2026 rubygems.org also shows advisory warnings on gem pages.

The routine

1. Check the lockfile on every CI run

bundler-audit compares your Gemfile.lock against the advisory database and also flags insecure gem sources:

gem install bundler-audit
bundle-audit check --update

--update fetches the latest advisories first. Without it the check runs against whatever copy of the database happens to be on the machine, which on a CI runner can be months old.

New Rails 8.1 applications already include bundler-audit and Brakeman, with a bin/bundler-audit binstub, a config/bundler-audit.yml ignore list and a CI job that runs both. One catch: in Rails 8.1.4.1 that binstub does not pass --update, so add it yourself in CI (bin/bundler-audit check --update) until a release fixes it. For an older application, add the two gems:

group :development, :test do
  gem "bundler-audit", require: false
  gem "brakeman", require: false
end

Brakeman checks your own code for vulnerabilities (SQL injection, unsafe redirects, mass assignment), which an advisory database cannot.

When an advisory does not apply to you, put its ID in the ignore list with a comment saying why, rather than turning the check off.

2. Apply security releases within days, not at the next upgrade

A security release changes only the patch number (8.1.4 to 8.1.4.1), so it is the cheapest update you will ever make. Keep it that small:

bundle update --patch --strict rails

--patch prefers the next patch version, and --strict makes that a hard limit, so the update cannot drag in a new minor version of something else. --conservative goes further and leaves the gem's dependencies alone. Run the test suite, deploy, done.

If you use Bundler's dependency cooldowns (Bundler 4.0.13 and later, opt-in), which skip versions newer than a set number of days, pass --cooldown 0 for an urgent security fix.

Turning on Dependabot security updates gets you a pull request whenever an advisory matches your lockfile. It complements the CI check; it does not replace it, because nothing stops you merging other work while the pull request sits there.

3. Do not forget Ruby itself

A Ruby patch release is the same kind of change: 3.4.11 to 3.4.12 should be a non-event. Two places to update:

• .ruby-version (and the ruby line in the Gemfile, if you pin the patch there), then reinstall and run the tests.
• Your Docker image. The official ruby:3.4-slim tag always points at the latest 3.4 patch, so rebuilding your image without the build cache picks it up. A tag pinned to a full version (ruby:3.4.11-slim) does not move, which is safer for reproducible builds but means bumping it by hand.

4. Know your end-of-life dates before they arrive

The routine above only works while your versions are still patched. When the Rails or Ruby series you run reaches end of life, security releases simply stop coming, and the Rails guide is blunt about it: from then on, dealing with security issues is your own responsibility.

So put the dates on a calendar. For a Rails 8.0 application, the upgrade to 8.1 is now overdue. For Ruby 3.3, plan the move to 3.4 or 4.0 before the end of March 2027. Upgrading one minor version at a time keeps each step small and reviewable; the jump only becomes a project when it has been put off for several versions.

A checklist

• [ ] CI runs bundle-audit check --update and Brakeman, and fails the build on a finding
• [ ] Someone receives the Rails security announcements and the ruby-lang.org security feed
• [ ] Dependabot security updates are on
• [ ] Security releases are applied with bundle update --patch --strict and deployed within days
• [ ] Ruby patch releases go into .ruby-version and the Docker image
• [ ] The end-of-life dates of your Rails and Ruby versions are on the calendar, with an upgrade planned before them

We run our own application, Japan Voyage, on the development branches of both Rails and Ruby, so we apply this routine every week. I am also a JRuby ambassador and contribute to JRuby itself, these days mostly its fiber support, and I have started on JRuby support in Rails. The Rails Foundation's This Week in Rails for the week of the 8.1.4.1 security release thanked me among the contributors whose pull requests were highlighted (the Rails Foundation's post). If your application is already on a version that no longer gets security fixes, or you would rather have someone else watch the announcements and apply the releases each month, that is what our Rails and Ruby upgrade service is for.