Clarification request: are security reports for EOL releases assessed?

[tomasz]

Hello,

I have been reviewing the documentation to determine how the project addresses vulnerabilities discovered in end-of-life (EOL) releases. Specifically whether CVE or GHSA advisories are published and maintained for such cases.

As part of a team responsible for maintaining a Rails application, I would find it helpful if the “Maintenance Policy for Ruby on Rails” page explicitly clarified this. If no formal approach currently exists, this may be a good opportunity to define one.

For reference, Node.js discontinued security assessments for EOL releases and issued catch-all advisories for outdated versions. MITRE rejected these advisories, and Node.js now assumes all EOL releases are vulnerable unless proven otherwise: https://nodejs.org/en/blog/vulnerability/updates-cve-for-end-of-life#why-nodejs-does-not-evaluate-eol-versions

[e_a]

The maintenance page spells all this out in pretty good detail. They provide 2 years of security fixes. After that it’s no longer supported. The page explicitly says:

When a release series is no longer supported, it’s your own responsibility to deal with bugs and security issues

That being said, there is a 3rd party organization that provides paid support for older releases.

[Ericbejlic890 (nickfreedy32)]

@tomasz

I have been reviewing the documentation to determine how the project addresses vulnerabilities discovered in end-of-life (EOL) releases. Specifically whether CVE or GHSA advisories are published and maintained for such cases.

As part of a team responsible for maintaining a Rails application, I would find it helpful if the “Maintenance Policy for Ruby on Rails” page explicitly clarified this. If no formal approach currently exists, this may be a good opportunity to define one.

For reference, Node.js discontinued security assessments for EOL releases and issued catch-all advisories for outdated versions. MITRE rejected these advisories, and Node.js now assumes all EOL releases are vulnerable unless proven otherwise: Node.js

You’re suggesting that the Rails “Maintenance Policy” should clearly state how vulnerabilities in EOL releases are handled whether CVE/GHSA advisories are published or not similar to how Node.js now treats all EOL versions as vulnerable unless proven otherwise.

[e_a]

@Ericbejlic890

You’re suggesting that the Rails “Maintenance Policy” should clearly state how vulnerabilities in EOL releases are handled whether CVE/GHSA advisories are published or not similar to how Node.js now treats all EOL versions as vulnerable unless proven otherwise.

Maybe I’m not following what you are asking but I’m suggesting the maintenance policy already does state how vulns in EOL releases are handled. It explicitly says it’s unsupported and your responsibility.

As to CVE, they often indicate the relevant version number in them. For example the most recent vuln in Rails says:

This has been assigned the CVE identifier CVE-2025-24293.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1

It’s making clear that vuln does not affect versions before 5.2 (I’m guessing that was when ActiveStorage was introduced). I’m not sure if every CVE includes that info but many do. Since running EOL is the user’s responsibility then regardless if the info is there are not if you are on an unsupported version you’ll have to examine each CVE and determine if it’s applicable (or pay someone to do that for you).