Ruby 3.2 Is EOL: What You Actually Need to Do
Ruby 3.2 hit end of life on March 31, 2026. What that actually means for your Rails app, your real risk, and why Ruby 3.4 is the target to upgrade to.
Ally Piechowski · · Updated · 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, and nothing will for a while. What changed is that the next vulnerability discovered in Ruby 3.2 will never be fixed by the maintainers.
What “End of Life” Means
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, and now it gets nothing.
Exposure
An internal admin tool behind a VPN and a customer-facing checkout flow have very different exposure. Both should upgrade, but the checkout flow goes first.
Compliance is where teams get surprised. If your app touches cardholder data, PCI DSS requirement 12.3.4, mandatory since March 31, 2025, requires a documented remediation plan for EOL software, approved by senior management. Running EOL Ruby in a PCI-scoped environment without that document is already a compliance gap, whether or not anyone has noticed yet. This is why, when I audit a codebase, I name the EOL date in the report instead of writing “outdated dependencies.” The people who have to sign the remediation plan need the actual date.
Healthcare has its own version coming, eventually. The HIPAA proposed rule eliminates the “addressable” distinction for security controls, making patching mandatory. It was supposed to finalize around May 2026 and didn’t; as of July 2026 there’s no final rule and no confirmed new date. When it does land, covered entities get 60 days before it takes effect and another 180 before enforcement kicks in.
The Upgrade Path
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 an expected EOL of March 2028, which gives you 2 years before the next one of these conversations. Ruby 3.3 (expected EOL March 2027) is the safer stop for risk-averse teams with limited test coverage, and Ruby 4.0 (expected EOL March 2029) only makes sense if you’re already on 3.4.
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 is the 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.
If You’re Also Behind on Rails
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.
If You Can’t Upgrade Right Now
Not every team can drop what they’re doing for a runtime upgrade. The difference between having a plan and ignoring the problem is mostly boring process work. Run bundle audit weekly, not just in CI (a cron job and a Slack webhook is plenty), so you find out when a new vulnerability drops even if you can’t patch the runtime yet. Write the plan down somewhere official: in a regulated industry, a written remediation timeline with management sign-off is what separates “we’re working on it” from “we were negligent” (that’s requirement 12.3.4 again). And put a date on the plan, even if it’s two months out.
Anyway, if you’re not sure how much work the upgrade involves, start with the dependency pass: bundle outdated, bundle exec bundle_report compatibility (via the next_rails gem, not stock Bundler), and a hard look at which files have zero test coverage before you touch the runtime.