PCI DSS Compliance: Why Your Rails 5.2 App Will Fail Its Next Audit

In the late 19th century, bank vault manufacturers engaged in a continuous arms race with bank robbers. Early vaults were built with incredibly thick iron walls and heavy doors, which seemed impenetrable. However, robbers soon discovered a structural flaw — not in the walls, but in the locks. By pouring liquid explosives into the keyhole or drilling a small hole to manipulate the tumblers, they bypassed the thick iron entirely. The banks thought they were secure because their perimeter was strong, but the core mechanism was outdated and vulnerable to newly discovered techniques. To maintain their insurance policies, banks were forced to systematically upgrade their entire locking mechanisms to modern time locks.

Similarly, for large and complex applications handling payment data, software modernization is not a technical preference; it is a strict regulatory requirement. You might have a robust Web Application Firewall (WAF), strict network policies, and modern encryption in transit. However, if your core application is running on Ruby on Rails 5.2, you are operating with an outdated, vulnerable mechanism.

This is not a theoretical risk. For organizations beholden to regulatory standards in the US, the UK, and globally, running unsupported software like Rails 5.2 will result in audit findings, heavy fines, and the potential loss of enterprise certifications. In this guide, we will examine exactly why a Rails 5.2 application fails modern PCI DSS compliance audits, how auditors detect these vulnerabilities, and the practical steps required to remediate the issue.

What PCI DSS Actually Requires

Before we get into the mechanics of Rails 5.2, let’s take a step back and talk about the Payment Card Industry Data Security Standard (PCI DSS) itself.

PCI DSS is a global security standard mandated by major credit card brands. It applies to any organization, regardless of size or geographic location, that accepts, transmits, or stores cardholder data. Whether your primary market is in New York, London, or Tokyo, the requirements remain rigorously enforced.

Strictly speaking, PCI DSS does not explicitly name Ruby on Rails or any specific framework. Instead, it mandates broad security practices. Requirement 6 of the PCI DSS v4.0 standard specifically dictates that organizations must develop and maintain secure systems and applications. This includes a strict mandate to install applicable vendor-supplied security patches within a specific timeframe (often 30 days for critical vulnerabilities).

This leads naturally to our main problem with Rails 5.2.

The End-of-Life Problem: Why Rails 5.2 Fails

Ruby on Rails 5.2 officially reached its End-of-Life (EOL) status in June 2022.

When a framework reaches EOL, the core team ceases all maintenance. This means no more bug fixes, no more performance improvements, and — crucially — no more security patches for newly discovered Common Vulnerabilities and Exposures (CVEs).

If a new, critical vulnerability is discovered in Action Pack or Active Record today, the Rails core team will release patches for Rails 7.2, 7.1, and perhaps 7.0. They will not release a patch for Rails 5.2.

Therefore, when an auditor examines your system, they will observe that you are running unsupported software with known, unpatched vulnerabilities. Under PCI DSS Requirement 6, this is an automatic failure. You cannot apply vendor-supplied security patches because the vendor no longer supplies them.

The Mechanics of the Audit Failure

One may wonder: how exactly do auditors know what version of Rails you are running? The answer is straightforward. Auditors use automated vulnerability scanners, and they also require you to run internal scans.

If we look at a typical Ruby project, the dependencies are strictly declared. Let’s run a common security auditing tool, bundler-audit, on a hypothetical legacy application:

$ bundle exec bundler-audit
Name: actionpack
Version: 5.2.8.1
Advisory: CVE-2023-28362
Criticality: High
URL: https://github.com/advisories/GHSA-m84j-xwvw-q2xw
Title: Cross-site-scripting via redirect_to in Action Pack
Solution: upgrade to >= 6.1.7.3, 7.0.4.3

Name: activesupport
Version: 5.2.8.1
Advisory: CVE-2023-22792
Criticality: Medium
URL: https://github.com/advisories/GHSA-jv25-xvjv-7rm9
Title: ReDoS vulnerability in Active Support
Solution: upgrade to >= 6.1.7.1, 7.0.4.1

Vulnerabilities found!

As we can see, running the above script explicitly flags vulnerabilities that have no official patch available for the 5.2.x series. You also may notice that the suggested solution for both vulnerabilities is to upgrade to a version in the 6.1.x or 7.0.x series. The implication here is stark: there is no path forward that involves remaining on the 5.2 branch.

Because bundler-audit only reads your Gemfile.lock and compares it against an external vulnerability database, it is a read-only process; it will not alter your application state. This makes it perfectly safe to integrate automatically into your Continuous Integration (CI) pipeline for continuous verification. The auditor’s compliance software will likely run a similar process, parse this exact dependency tree, and flag the EOL framework.

Mitigation vs. Remediation

There are, of course, multiple ways to address a failed audit. When faced with the immense technical debt of upgrading a legacy application, some engineering teams attempt to use “compensating controls” to satisfy the auditor without actually doing a Ruby and Rails upgrade.

For example, you might argue that your WAF blocks the specific malicious payloads, or that the vulnerable code paths are never actually executed in your production environment.

This approach, though, is inherently fragile. Compensating controls require extensive documentation, explicit auditor approval, and continuous manual verification. They do not fix the underlying vulnerability; they merely attempt to put a stronger perimeter around the broken lock. Eventually, the auditor will reject the compensating control, or a new vulnerability will emerge that your WAF cannot reliably intercept. The only permanent, durable solution is technical debt remediation through a framework upgrade.

The Path Forward: Upgrading Safely

There are three major approaches to upgrading a legacy Rails application from 5.2 to a supported version like 7.2 or 8.0. Depending on the particular circumstances you find yourself in, one of them may be more useful than the other two.

The first is the “big bang” approach, where a team stops all new feature development, creates a long-lived branch, and attempts to fix every deprecation warning and test failure at once. This is generally the most dangerous method; by the time the upgrade is finished months later, the main branch has diverged so significantly that merging becomes a nightmare.

The second is a series of gradual version bumps. You upgrade from 5.2 to 6.0, run the test suite, fix deprecations, and deploy to production. Then, a few weeks later, you move from 6.0 to 6.1. This approach, though, still requires halting feature work during each bump.

The third option is dual-booting; this is my preferred method. In a dual-boot setup, you use a library like next_rails to generate a Gemfile.next.lock. This allows your application to boot under both Rails 5.2 and Rails 6.0 simultaneously.

$ bundle exec next_rails bundle_report outdated

Note the use of bundle exec; we could have run next_rails directly if it were installed system-wide, but running it through bundle exec guarantees we use the exact version specified in our application’s environment. This avoids unexpected version mismatches.

With dual-booting, your Continuous Integration (CI) pipeline runs the test suite against both versions. Developers can continue shipping features on Rails 5.2 while simultaneously fixing deprecation warnings in the Rails 6.0 environment. Once the 6.0 test suite is completely green, you can transition in production.

Generally speaking, the third option is the most reliable for large, complex applications. It provides the safest path to modernize your codebase, satisfy your PCI DSS auditors, and protect your organization from reputational damage and heavy fines — all without bringing your product roadmap to a standstill.