Rails 8.0 Security Support Ends 7 November 2026: Move to 8.1 Now

Rails 8.0 stops receiving security fixes on 7 November 2026, two years after 8.0.0, under the Rails maintenance policy. After that date only Rails 8.1 gets them, until 10 October 2027. Ten of this year's twelve Rails advisories shipped an 8.0 fix, including a critical one. Get onto 8.0.5.1 today and move to 8.1 before the deadline.

This guide is for teams running Rails 8.0 or older: engineers doing the upgrade, and the people who have to answer "which of our apps are on an unsupported framework" for an audit or a customer questionnaire. It covers what the policy says and what it does not, every 2026 advisory that 8.0 received with its fixed versions, why 8.1 is a small step and where the real work hides, a script that finds every Rails app in a directory and reports its status, and a step by step upgrade with commands.

The short answer

Rails 8.0.x security support ends on 7 November 2026. Rails 8.1.x is supported for security fixes until 10 October 2027. Rails 7.2 and older no longer appear on the maintenance page's supported list. Rails 8.1 requires the same Ruby as 8.0, version 3.2.0 or later, and the official upgrade guide lists one behavior change for the move: column order in schema.rb. The 8.1 release notes add a short list of removals of features that 8.0 deprecated, and those are where most upgrade time goes. Today, make sure every 8.0 app is on 8.0.5.1, the latest 8.0 security release. Before 7 November, upgrade to 8.1.4 or later.

Fourteen days remain as of 24 October 2026. There is no 8.0 security release scheduled; the next one, if any, would only come if a vulnerability is disclosed before the deadline.

What changed since 20 October

We first drafted this guide on 20 October and re-checked every source on 24 October.

1. No new Rails releases. RubyGems shows 8.1.4 and 7.2.4, both from 24 September 2026, as the newest Rails versions. The newest 8.0 release is still 8.0.5.1 from 29 July 2026. There is no 8.2 release or prerelease of rails or railties on RubyGems.
2. No new advisories for the Rails component gems. Querying OSV for the twelve component gems and the rails gem itself still returns twelve advisories published in 2026, the latest on 30 July. Ten list an 8.0 fixed version. The count in our 20 October draft holds.
3. The deadline is two weeks away. The maintenance page still lists 8.0.x security support until 7 November 2026, unchanged.
4. We added Ruby to the picture. Ruby 3.2 reached end of life on 1 April 2026, according to ruby-lang.org. Rails 8.0 and 8.1 both still accept Ruby 3.2, so an app can be on a supported Rails and an unsupported Ruby at the same time. Our checker script now flags that too.
5. We read the 8.1 release notes in full. The upgrade guide lists one change, but the release notes list removals across Railties, Action Pack, Active Record, Active Storage, Active Support and Active Job. Those are now covered in their own section, with commands to find each one.

Timeline

What the policy says

The Rails maintenance policy, published at rubyonrails.org/maintenance, splits support into three groups: new features, bug fixes and security issues.

• New features. The team aims to release a version with new features every six months. If no release is made in a year, the support period for the previous release is extended until the next release.
• Bug fixes. Each minor series gets bug fixes for one year after its first release.
• Security issues. Each minor series gets security fixes for two years after its first release. After that, it reaches end of life.

The supported lists on 24 October 2026 read:

Two things in that table deserve a comment.

First, both bug fix dates have passed. The page still lists them, and the policy's extension rule says that when no new release has been made in a year, the previous release's support is extended until the next one. No 8.2 had been released by 24 October. Read the 8.1 bug fix date as "until 8.2 ships", which is how the policy words it, and do not plan around a new 8.0 bug fix release: 8.0's last bug fix release was 8.0.5 on 24 March 2026, and everything since has been security only.

Second, the 8.1 security date, 10 October 2027, is about two weeks earlier than two years after the 8.1.0 gem appeared on RubyGems on 22 October 2025. We use the date the page publishes. The 8.0 date matches 8.0.0's RubyGems date exactly.

For unsupported series, the policy says the team "may provide backports of the fixes and publish them to git", but releases no new versions. Rails 7.2.4 did appear on 24 September 2026, after 7.2's two year window, so the team does sometimes ship more. Treat that as an exception, not a plan: nothing in the policy promises it, and the page no longer lists 7.2 at all.

Technical details

What Rails 8.0 received in 2026

These are every advisory published in 2026 for the twelve Rails component gems (actionpack, actionview, activerecord, activemodel, activesupport, activestorage, actiontext, actionmailer, actionmailbox, activejob, actioncable, railties), from the OSV database, which mirrors the GitHub reviewed advisories. Severity is the GitHub advisory's rating.

Counting it up: 12 advisories. 10 list an 8.0 fixed version, nine at 8.0.4.1 in March and one at 8.0.5.1 in July. CVE-2026-33167 lists a fix for 8.1 only, because its affected range starts at 8.1.0; Rails 8.0 never had the vulnerable code. The January Active Job record describes an issue fixed in 4.2.0.beta2 and does not touch any current line.

Active Storage accounts for seven of the twelve, including the only high and the only critical issue. If your 8.0 app uses Active Storage, and especially if it accepts uploads from users, the end of 8.0 support matters more for you than for an API only app.

CVSS vectors

OSV carries the GitHub advisories' CVSS 4.0 vectors. Two examples show the range:

CVE-2026-66066 in brief

The July critical issue is the clearest example of what an end of life line stops receiving. According to the Rails announcement, an application that uses libvips for Active Storage image processing and accepts image uploads from untrusted users may allow an unauthenticated attacker to read arbitrary files, including the process environment, which usually holds secret_key_base. The fix disables libvips operations that libvips marks as unsafe for untrusted content. The announcement adds that libvips must be 8.13 or later, and that Active Storage refuses to boot on older libvips. It also tells affected apps to rotate secret_key_base and every secret the process could read. We covered it in depth in our post on CVE-2026-66066. If a similar issue is found on 8 November, an 8.0 app gets no gem.

Outside the component gems

Rails apps also depend on gems the core team maintains outside the twelve components. In July, the Rails HTML sanitizer gem got CVE-2026-73648, GHSA-cj75-f6xr-r4g7, a moderate XSS under certain configurations, affecting rails-html-sanitizer from 1.0.3 and fixed in 1.7.1. That gem has its own versioning and is not tied to the 8.0 deadline, so do not assume that moving to 8.1 updates it. Check it separately.

Release versions and Ruby requirements

Ruby support next to Rails support

Rails 8.1 accepts Ruby 3.2, but Ruby 3.2 itself no longer gets security fixes. If you are touching the Gemfile anyway, move Ruby to a supported branch in the same project, as a separate pull request so the two changes are easy to bisect.

Affected and fixed versions by line

Who is affected

• Any app on Rails 8.0.x. It keeps working after 7 November, but newly found vulnerabilities in 8.0 will get no released fix.
• Apps below 8.0.5.1 today. They are missing the July critical fix, and apps below 8.0.4.1 are also missing the nine March fixes. That risk exists now, not on 7 November.
• Apps on 7.2 or older. They are already off the supported list. Moving them to 8.1 is a longer path, through 8.0 first, as the upgrade guide recommends moving one minor version at a time.
• Gems and engines that pin rails to 8.0. An internal engine with gem "rails", "~> 8.0.0" in its gemspec blocks every app that uses it. Find those first.
• Compliance and questionnaire owners. Many security questionnaires and audit controls ask whether frameworks are vendor supported. From 8 November, an 8.0 app answers no.

Why 8.1 is a small step, and where the work hides

Two things usually make a framework upgrade expensive: a new language version and breaking changes. The first does not apply here, and the second is limited.

Same Ruby. RubyGems lists 8.0.5.1 and 8.1.4 with the same requirement, Ruby 3.2.0 or later.

One listed behavior change. The upgrading guide's section for 8.0 to 8.1 describes one change: Active Record sorts table columns alphabetically in schema.rb by default, so dumps stay consistent across machines. That produces a one time diff in schema.rb. If you need the exact database column order, structure.sql still preserves it.

The removals. The 8.1 release notes list features deprecated in 8.0 and removed in 8.1. If your app heeded 8.0's deprecation warnings, these are already gone from your code. If it did not, these are the lines that break:

The query string changes are worth a second look for API apps. A client that sends a=1;b=2 and expects two parameters will now get one parameter a with the value 1;b=2. That is a behavior change your tests may not cover if they build requests with hashes rather than raw strings.

The deprecations. 8.1 also deprecates, without removing, several things you will see as warnings: order dependent finders such as first without an order, ActiveRecord::Base.signed_id_verifier_secret, insert_all and upsert_all with unpersisted records in associations, WITH, WITH RECURSIVE and DISTINCT with update_all, String#mb_chars, ActiveSupport::Configurable, config.active_support.to_time_preserves_timezone, and the built in Sidekiq adapter, which now lives in the sidekiq gem. None of these block the upgrade, but each will be a removal in a later version.

Find every Rails app

This script walks a directory, reads the railties version and the locked Ruby version from each Gemfile.lock, and reports security support status from the Rails maintenance page and Ruby's branch list, both read on 24 October 2026. It also flags apps below their line's latest security release. Standard library only; it reads files and changes nothing.

#!/usr/bin/env python3
"""Find Rails apps under a directory and report security support status.

Reads each Gemfile.lock for the railties version (present in every Rails app)
and the locked Ruby version, and compares them with the Rails maintenance
policy (rubyonrails.org/maintenance) and Ruby's branch list
(ruby-lang.org/en/downloads/branches), both read on 24 October 2026.
Skips vendor/ and node_modules/. Standard library only.

Usage: python3 rails_support_check.py ~/code
"""
import datetime
import pathlib
import re
import sys

RAILS_SECURITY_UNTIL = {(8, 1): "2027-10-10", (8, 0): "2026-11-07"}
RAILS_LAST_SECURITY = {(8, 1): (8, 1, 3, 1), (8, 0): (8, 0, 5, 1)}
RUBY_EOL = {(3, 2): "2026-04-01", (3, 1): "2025-03-26", (3, 0): "2024-04-23"}
TODAY = datetime.date.today()


def vtuple(v):
    return tuple(int(x) for x in re.findall(r"\d+", v))


def read_lock(lock):
    text = lock.read_text(errors="replace")
    rails = re.search(r"^    railties \(([\d.]+)\)$", text, re.M)
    ruby = re.search(r"^RUBY VERSION\n\s+ruby ([\d.]+)", text, re.M)
    return (rails.group(1) if rails else None, ruby.group(1) if ruby else None)


def rails_status(v):
    t = vtuple(v)
    line = t[:2]
    until = RAILS_SECURITY_UNTIL.get(line)
    if until is None:
        return "FAIL no longer receives security fixes"
    last = RAILS_LAST_SECURITY[line]
    behind = "" if t >= last else f"; below {'.'.join(map(str, last))}"
    days = (datetime.date.fromisoformat(until) - TODAY).days
    if days < 0:
        return f"FAIL security support ended {until}{behind}"
    if days <= 31:
        return f"PLAN security support ends {until} ({days} days){behind}"
    return f"ok   security support until {until}{behind}"


def ruby_status(v):
    if not v:
        return "ruby not locked"
    eol = RUBY_EOL.get(vtuple(v)[:2])
    if eol and datetime.date.fromisoformat(eol) <= TODAY:
        return f"ruby {v} EOL since {eol}"
    if vtuple(v)[:2] < (3, 0):
        return f"ruby {v} EOL"
    return f"ruby {v}"


def main(root):
    for lock in sorted(pathlib.Path(root).rglob("Gemfile.lock")):
        if {"vendor", "node_modules"} & set(lock.parts):
            continue
        rails, ruby = read_lock(lock)
        if rails:
            print(f"{str(lock.parent):<16} rails {rails:<9} {rails_status(rails)} | {ruby_status(ruby)}")


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else ".")

We ran it on four fixture apps on 24 October 2026. The day counts reflect that date; after 7 November the 8.0 rows switch to FAIL on their own.

$ python3 rails_support_check.py apps
apps/api         rails 7.2.3.2   FAIL no longer receives security fixes | ruby 3.3.6
apps/billing     rails 8.1.4     ok   security support until 2027-10-10 | ruby 3.4.7
apps/crm         rails 8.0.5.1   PLAN security support ends 2026-11-07 (14 days) | ruby 3.3.6
apps/intranet    rails 8.0.4     PLAN security support ends 2026-11-07 (14 days); below 8.0.5.1 | ruby 3.2.6 EOL since 2026-04-01

The intranet app is the one to fix today. It is on 8.0.4, below both the March and July security releases, and on an end of life Ruby. The CRM app is current for 8.0 and needs the 8.1 upgrade within two weeks. The API app is on 7.2 and needs the longer path. For 7.2 specifically, see our earlier post on what the maintenance page lists for 7.2.

Step by step: from 8.0 to 8.1

Step 1: confirm the version you actually run

The Gemfile says what you asked for; Gemfile.lock says what you get. Check the lock, and check a running instance if you can.

# What the lockfile resolves to
bundle exec rails -v
bundle info railties
grep -E '^    (rails|railties|activestorage|rails-html-sanitizer) \(' Gemfile.lock

# Any internal gem or engine that pins Rails to 8.0
grep -rnE "add_(runtime_)?dependency.*['\"](rails|railties)['\"].*8\.0" --include=*.gemspec .

# Ruby the app is locked to
sed -n '/^RUBY VERSION/,+1p' Gemfile.lock

For container images, run bundle exec rails -v inside the image you deploy, not on a developer laptop. Images often lag the repository.

Step 2: get onto 8.0.5.1 now

If any 8.0 app is below 8.0.5.1, fix that first. It is a patch level change with no new features.

bundle update rails --conservative
bundle exec rails -v          # expect Rails 8.0.5.1
bin/rails test                # or bundle exec rspec

If the app uses Active Storage with libvips, check the libvips version on every host and image as well, because the CVE-2026-66066 fix requires 8.13 or later and Active Storage refuses to boot below that:

vips --version
pkg-config --modversion vips

Step 3: audit dependencies

gem install bundler-audit
bundle audit check --update

bundler-audit checks Gemfile.lock against the Ruby advisory database. New Rails 8.1 apps include a bin/bundler-audit step in their default config/ci.rb, according to the 8.1 release notes.

Step 4: clear 8.0 deprecation warnings

The upgrade guide recommends moving one minor version at a time and using deprecation warnings as your map. Make them fail loudly in the test environment before you bump the version:

# config/environments/test.rb
config.active_support.deprecation = :raise

Run the suite, fix what raises, then search for the specific removals from the table above:

grep -rn "Benchmark\.ms" app lib config
grep -rnE "service: *[\"']?(Azure|azure)" config/storage.yml
grep -rn "enqueue_after_transaction_commit" app config
grep -rnE "unsigned_(float|decimal)" db app lib
grep -rnE "^\s*retries:" config/database.yml
grep -rn "STATS_DIRECTORIES\|rails/console/methods" lib config Rakefile
grep -rn "SuckerPunch\|sucker_punch" config Gemfile
grep -rn "mb_chars" app lib

Each hit is a line to change before or during the upgrade. For Benchmark.ms, add the benchmark gem or use Process.clock_gettime. For the :azure service, the 8.1 notes list it as removed, so plan a move to another storage service before the upgrade.

Step 5: bump to 8.1

Follow the upgrade guide's process:

# Gemfile
gem "rails", "~> 8.1.4"

bundle update rails
bin/rails app:update

bin/rails app:update walks through changed configuration files interactively and creates config/initializers/new_framework_defaults_8_1.rb. Review every diff before accepting it. If you use jsbundling, update the Rails JavaScript packages in package.json too, as the guide's version steps describe.

Step 6: adopt the new defaults gradually

After app:update, the app still runs with 8.0 defaults, because config.load_defaults in config/application.rb has not changed. Uncomment settings in new_framework_defaults_8_1.rb one at a time, across deploys if you like. When all are on, delete that file and set:

# config/application.rb
config.load_defaults 8.1

Step 7: commit the schema reorder on its own

Run a migration or bin/rails db:schema:dump and commit the reordered schema.rb as a separate commit with a clear message. Reviewers can then confirm it only moves columns, and future diffs stay clean. If you depend on column order, switch to structure.sql:

# config/application.rb
config.active_record.schema_format = :sql

Step 8: test the raw request paths

Because 8.1 changes how semicolons and leading brackets in query strings parse, add a request test that sends raw query strings your real clients send. Then run the full suite, deploy to staging, and watch logs for parameter errors.

Step 9: confirm and record

bundle exec rails -v              # expect Rails 8.1.4 or later
bundle audit check --update
python3 rails_support_check.py .  # expect "ok"

Record the new version in your SBOM or asset inventory so the next audit question has a recorded answer.

If you cannot upgrade by 7 November

Some apps will miss the date. Be honest about what that means.

• No new 8.0 gems. The policy says unsupported series get no new versions. The team may publish backports to git, but you would have to find, review and apply them yourself, or point your Gemfile at a git ref, which most production change processes will not accept for long.
• Compensating controls buy time, not support. A web application firewall rule, disabling Active Storage uploads for untrusted users, or isolating an internal app all reduce exposure to a specific bug once one is found. None of them replaces a patched framework.
• Write it down. Record each app that will be on 8.0 after 7 November with an owner and a target date. An exception with a date is a plan; an app nobody tracks is the one that is still on 8.0 in 2028.

Open questions

• When does Rails 8.2 ship? None of the sources we checked give a date, and no prerelease is on RubyGems. When it ships, the extended 8.1 bug fix window ends under the policy.
• Will there be one more 8.0 security release? Only if a vulnerability is disclosed and fixed before 7 November. None was announced by 24 October.
• Why is the 8.1 security date 10 October 2027? It is about two weeks earlier than two years after the 8.1.0 gem. The page is the authority; plan to that date.

The fair view

Two years of security fixes per minor series, on published dates, is a clear policy, and the Rails team backed 8.0 with two rounds of security releases this year, in March and in July, including a critical fix with a detailed incident write up. The 8.0 to 8.1 upgrade is also one of the gentlest Rails has had: no Ruby bump and one listed behavior change.

What makes deadlines like this one bite is not the work per app but the number of apps. A company with dozens of small Rails services, each on whatever version it started with, finds out on 8 November how many are now unsupported. The script above is the five minute way to find out first.

What would have helped

Practices any team can use

• An inventory that knows framework versions. If every repository and image has an SBOM, "which apps are on Rails 8.0" is a query, not a survey.
• End of life dates in the same system as vulnerabilities. Treat a framework line's security end date as a finding with a due date, and assign it to an owner months ahead.
• Patch level updates on a schedule. Apps that take every security release within days, like 8.0.4.1 in March and 8.0.5.1 in July, are also the apps whose minor upgrades are small, because they were never far behind.
• Deprecation warnings treated as failures in tests. That turns the next upgrade's removals into today's small fixes.
• One version policy for internal engines. Engines and shared gems should allow the next minor as soon as it exists, so they never become the reason an app cannot upgrade.
• Ruby and Rails reviewed together. Ruby 3.2 left support in April while Rails still accepted it. Check both.

Where Safeguard fits

• Finding every Rails app. safeguard scan --dir . on a repository, safeguard scan --image <name> on a container image, or safeguard scan --sbom <file> on an SBOM inventories dependencies from the lockfile and writes results as JSON under ./output. In the platform you can see which projects contain a given component and version, such as railties 8.0.x, across the whole estate.
• Matching advisories. Safeguard matches components against vulnerability databases, so the 2026 Rails advisories show up against the apps still below their fixed versions. Reachability analysis is designed to rank first the vulnerable code paths an app actually calls, which separates an Active Storage app from an API only app.
• Gating new work. Policies and gates evaluated in the platform can flag a framework version you have decided not to ship, so a new service does not start on an expiring line.
• Doing the upgrade with you. The Safeguard CLI's assistant can edit code and run commands with your approval: bump the Gemfile, run bundle update, run the grep checks above, fix removals and run the tests, stopping for your approval under the /permissions mode you choose.

Where Safeguard does not help: it cannot extend Rails support or produce official Rails security releases, and it cannot judge whether your tests cover the query string behavior that 8.1 changes. Those remain the Rails team's and your team's work.

Common mistakes

• Reading the Gemfile instead of the lockfile. gem "rails", "~> 8.0" tells you little. Gemfile.lock and bundle exec rails -v tell you what runs.
• Assuming 8.0.5.1 is safe after 7 November. It is the latest 8.0 release, and it stops being supported on 7 November like every 8.0 version.
• Skipping the 8.0 security releases because the upgrade is coming. An app on 8.0.4 is missing a critical fix today. Patch first, then upgrade.
• Forgetting libvips. The CVE-2026-66066 fix needs libvips 8.13 or later in every image. An old base image breaks boot after the gem update.
• Upgrading Rails and Ruby in one pull request. When something breaks, you will want to know which change did it.
• Burying the schema.rb reorder in a feature diff. Commit it alone.
• Treating 7.2.4 as a sign that 7.2 is supported. The policy promises nothing for unsupported lines, and the page no longer lists 7.2.
• Missing internal engines. One gemspec pinned to 8.0 can block a dozen apps.
• Assuming 8.1 updates rails-html-sanitizer. It is a separate gem with its own advisories, including CVE-2026-73648 in July.

FAQ

When does Rails 8.0 reach end of life?

Security support for Rails 8.0.x ends on 7 November 2026, according to rubyonrails.org/maintenance. Bug fix support, as the page lists it, ended on 7 May 2026.

My app runs Rails 8.0.5.1. Is it supported on 8 November 2026?

No. 8.0.5.1 is the latest 8.0 security release, but the whole 8.0 line leaves security support on 7 November. Upgrade to 8.1.

How long is Rails 8.1 supported?

Security fixes until 10 October 2027, per the maintenance page. Bug fixes are listed until 10 October 2026 and, under the policy's extension rule, continue until the next feature release when none has shipped within a year.

Do I need a newer Ruby to move from Rails 8.0 to 8.1?

No. RubyGems lists both 8.0.5.1 and 8.1.4 as requiring Ruby 3.2.0 or later. Separately, Ruby 3.2 reached end of life on 1 April 2026, so consider moving Ruby too, in its own change.

What breaks when upgrading from Rails 8.0 to 8.1?

The upgrade guide lists one change, alphabetical columns in schema.rb. The release notes remove features that 8.0 deprecated, including Benchmark.ms, the :azure Active Storage service, semicolon query string separators and some Active Job settings. If your app ran clean of 8.0 deprecation warnings, most apps need little else.

How many security fixes did Rails 8.0 get in 2026?

Ten advisories listed an 8.0 fixed version: nine in 8.0.4.1 on 23 March and one critical fix, CVE-2026-66066, in 8.0.5.1 on 29 July. Of the two other 2026 advisories, CVE-2026-33167 only affects 8.1, and the other concerns a Rails 4.2 beta era issue.

Is Rails 7.2 still supported?

It no longer appears on the maintenance page's supported list. Its two year window ran out in August 2026. A 7.2.4 release appeared on 24 September 2026, but the policy does not promise further 7.2 releases.

What happens if a vulnerability is found in Rails 8.0 after 7 November?

Under the policy, no new 8.0 gem is released. The team may publish backported fixes to git, but applying them is your responsibility.

Will my app stop working on 7 November?

No. Nothing changes in the running app. What changes is that new vulnerabilities in 8.0 get no released fix, and supported status answers in audits and questionnaires change from yes to no.

Can I skip 8.1 and wait for 8.2?

Not safely. No 8.2 release or prerelease existed on 24 October, and 8.0 leaves security support on 7 November. Move to 8.1 now; 8.1 to 8.2 later will be a separate, smaller step.

For the July critical fix in detail, read our post on CVE-2026-66066 in Active Storage. If you want to try the scan and fix flow on your own apps, the Safeguard apps are at safeguard.sh/download and the CLI guide is at docs.safeguard.sh/docs/cli.

Fix it without waiting for upstream

For Rails 8.0, the upstream fix after 7 November is a supported release line, 8.1, and the work is moving to it. The block below covers how to make that move faster, and what to do for components where upstream will not ship a fix.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These demos are recordings of real sessions on other fixes. None of them shows a Rails upgrade. Each shows a flow you would use the same way here.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and the advisory, asks before each command, edits package.json, runs the install and the tests with your approval, and pushes nothing. For a Rails 8.0 app you would ask it to move the app to 8.1.4, and it would edit the Gemfile, run bundle update rails and bin/rails app:update, run the removal greps and the test suite, asking before each step.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session appearing in the conversation list, asking for work on your computer, picking the folder, and approving or denying each command and file edit until the upgrade is done and tests pass. That is the shape of a Rails patch level bump to 8.0.5.1 across several app folders, one approval at a time.

Click through it at your own pace, or open it full screen.

The mobile app demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. With two weeks to the deadline, that lets you approve the next bundle update or test run on an upgrade branch without waiting to be back at your desk.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Rails maintenance policy
• RubyGems: Rails versions
• RubyGems: railties versions
• RubyGems: rails gem summary
• Upgrading Ruby on Rails guide
• Ruby on Rails 8.1 release notes
• Rails security announcements forum
• CVE-2026-66066 announcement: Active Storage variant processing
• OSV: GHSA-xr9x-r78c-5hrm (CVE-2026-66066)
• OSV: GHSA-9xrj-h377-fr87 (CVE-2026-33195)
• OSV: GHSA-pgm4-439c-5jp6 (CVE-2026-33167)
• OSV: GHSA-p9fm-f462-ggrg (CVE-2026-33658)
• OSV: GHSA-cj75-f6xr-r4g7 (CVE-2026-73648, rails-html-sanitizer)
• OSV query API
• Ruby maintenance branches

Last reviewed: 24 October 2026. Check the Rails maintenance page and security announcements for the latest status before 7 November.