Ruby 3.2 hit end of life on March 31, 2026. Here's what that actually means for your Rails app, how to assess your real risk, and the fastest safe upgrade path, without the vendor panic.
Ally Piechowski · · 4 min readOn March 27, Ruby 3.2.11 shipped with a fix for CVE-2026-27820, a buffer overflow in Zlib::GzipReader. Four days later, Ruby 3.2 hit end of life. That patch was the last one this version will ever receive.
Nothing broke on April 1. But the clock started. The next vulnerability discovered in Ruby 3.2 will never be fixed by the maintainers. And the Ruby security team addresses roughly 6 to 12 CVEs per year.
Ruby maintains three support phases: active maintenance (bug fixes and security patches), security maintenance (security patches only), and end of life (nothing). Ruby 3.2 spent its final year in security-only mode after Ruby 3.3 took over as the stable branch. Now it gets nothing.
When Ruby 3.1 hit EOL last March, a significant share of production apps never upgraded. The next CVE that lands gets patched in 3.3 and 3.4. Ruby 3.2 just stays vulnerable.
Is the app internet-facing? An internal admin tool behind a VPN has different exposure than a customer-facing checkout flow. Both should upgrade, but the checkout flow goes first.
Do you handle sensitive data? If your app touches cardholder data, PCI DSS 4.0 (mandatory since March 2025) now requires a documented remediation plan for EOL software, approved by senior management. Running EOL Ruby in a PCI-scoped environment without that documentation is already a compliance gap.
If you’re in healthcare: the HIPAA proposed rule finalizing around May 2026 eliminates the “addressable” distinction for security controls, making patching mandatory. The compliance window is 180 to 240 days after finalization.
If any of that describes your app, this is a this-week conversation.
| Version | Expected EOL | Recommended for |
|---|---|---|
| Ruby 3.3 | March 2027 | Risk-averse teams, limited test coverage |
| Ruby 3.4 | March 2028 | Most teams. Best balance of stability and runway |
| Ruby 4.0 | March 2029 | Only if you’re already on 3.4 |
Target Ruby 3.4 unless you have a reason not to. It has over a year of production adoption, full Rails 7.2+ and Rails 8 support, and gives you two years before the next EOL conversation.
The recommended path is 3.2 to 3.3 to 3.4, stepping through the intermediate version so deprecation warnings surface before they become hard errors in 3.4. But if you have solid test coverage and need to move fast, going direct from 3.2 to 3.4 is viable. The 3.3 deprecations rarely affect typical Rails application code.
The sneakiest breaking change in 3.4: bundled gems. base64, csv, bigdecimal, and several others are no longer default gems. Any code that does require 'csv' without a corresponding Gemfile entry will hit a LoadError that won’t tell you the cause is the runtime upgrade, just a missing file. Older Rails apps (especially those dating back to the 4.x or 5.x era) almost always have implicit dependencies on these. If you step through 3.3 first, you’ll get explicit deprecation warnings that name each affected gem before 3.4 makes them errors.
One more to watch: Ruby 3.4 introduces it as an anonymous block parameter. Code that uses it as a local variable or method name inside a block will silently change behavior. Ruby 3.3 warns about this; 3.4 just does it.
This is the compound problem I keep seeing in audits. Rails 7.0 security support ended April 2025. Rails 7.1 ended October 2025. If you’re on Ruby 3.2 and Rails 7.0 or 7.1, you’re running two unsupported layers simultaneously.
Upgrade Ruby first. It’s the lower-risk change and it unblocks the Rails upgrade. I wrote about what breaks in the Rails 7 to 8 jump if you’re planning that next.
Not every team can drop what they’re doing for a runtime upgrade. But there’s a difference between “we have a plan” and “we’re ignoring it.”
Run bundle audit weekly, not just in CI. You need to know when a new vulnerability drops, even if you can’t patch the runtime.
Write down the plan. In a regulated industry, a written remediation timeline with management sign-off is the difference between “we’re working on it” and “we were negligent.” PCI DSS 12.3.4 explicitly requires this for EOL software.
Set a deadline. “We’ll get to it” turns into never. Put a date on it, even if it’s two months out.
If you’re not sure how much work the upgrade involves, or what else the runtime change might shake loose, an audit is the fastest way to find out.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。