Your EOL Open Source Is a PCI DSS Compliance Problem — Here's How to Fix It

If your organization accepts, transmits, or processes payment card data (e.g. credit or debit cards), even if you use a third party to help you accept, transmit, or process payment card data, or if your organization develops software to help other organizations accept, transmit, or process payment card data, your software stack has likely become a compliance liability. As of March 31, 2025, the Payment Card Industry Data Security Standard's (PCI DSS) 4.0 compliance requirement (more specifically, Requirement 12.3.4) is now fully enforceable — and it has everything to do with the end-of-life (EOL) open source software within your software stack.

PCI DSS 4.0 focuses on multi-factor authentication, encryption, and network segmentation. Those are important. But there's a requirement that should be top of mind for engineering and security teams, and it targets outdated and unsupported software directly.

Requirement 12.3.4 was a "future-dated" requirement in PCI DSS 4.0 — meaning it was classified as a best practice through March 2025. Many organizations that completed their initial PCI 4.0 transition may not have fully addressed it. Now, in their first full assessment cycle under the complete standard, those same organizations are discovering this obligation applies to them, an obligation that the PCI Security Standards Council will not ignore.

‍

What PCI DSS 4.0 Actually Says About End-of-Life Software

PCI DSS 4.0.1 includes a requirement that should be on every compliance officer's radar: Requirement 12.3.4. It mandates that organizations review all hardware and software technologies in use at least once every 12 months, specifically to confirm that each component continues to receive security fixes from its vendor.

When a technology is identified as end-of-life or no longer supported, the organization must create a documented remediation plan — one that is approved by senior management — that addresses how and when the outdated technology will be remediated. Until it is, the organization is operating with a documented compliance gap that is visible to assessors.

This isn't just a technical issue — it's an executive-level obligation. The senior management approval requirement means EOL software can no longer live quietly in the backlog. It must be formally escalated, documented, and signed off by leadership. For CISOs and CTOs, this creates personal visibility into a risk they may not have been tracking.

This requirement works hand-in-hand with Requirement 6.3.3, which mandates that critical security patches be installed within one month of release. For EOL software, there are no patches to install. The community and/or project has moved on. That means any organization running EOL open source in its payment card data environment is simultaneously unable to meet the patching requirement and carrying a documented remediation obligation under Requirement 12.3.4.

Additionally, Requirement 6.3.2 requires organizations to maintain an inventory of all third-party software components incorporated into their applications. This means the identification burden is explicit — you're expected to know which components are in your stack, which creates a direct path for assessors to check whether any of those components have reached end-of-life.

The consequences of non-compliance are concrete: fines levied by card brands through your acquiring bank, increased transaction fees, mandatory forensic investigations, potential loss of the ability to accept payment cards entirely, and exposure to lawsuits. For any business that depends on card payments these are existential risks. HeroDevs can help bridge such risks.

‍

Two Real-World Examples

CVE-2026-22732: This critical security header omission vulnerability in Spring Security carries a CVSS 3.1 base score of 9.1 out of 10. It affects Spring Security versions stretching back to 5.7.x. For all EOL versions, there is no upstream patch. If your payment processing infrastructure relies on legacy Spring Security, you have a system that contains a critical unpatched access control bypass, cannot meet the 30-day patching timeline under Requirement 6.3.3, requires a senior-management-approved remediation plan under Requirement 12.3.4, and creates a documented compliance gap that is visible during your next PCI assessment.

CVE-2026-27970: This cross-site scripting vulnerability in AngularJS allows attackers to execute arbitrary JavaScript through compromised translation files. AngularJS reached end-of-life in December 2021, and no further upstream patches will be issued. If your customer-facing payment portal or checkout flow runs on AngularJS, you have a system with a known XSS vulnerability in a component that handles or is adjacent to payment card data, no path to an upstream fix, and a compliance gap under both Requirement 6.3.3 and Requirement 12.3.4.

To see if your organization could also be impacted, the HeroDevs Vulnerability Directory tracks hundreds of CVEs across EOL frameworks that are still widely deployed in enterprise environments, including critical issues in end-of-life versions of Spring Boot, Node.js, .NET, AngularJS, Angular, and many more.

‍

So What Do You Actually Do About It?

The obvious answer is "migrate to a supported version." While that's the right long-term play, anyone who's led a major framework migration knows the reality: these projects take time, require extensive regression testing, compete with product roadmap priorities, and require significant resources. In a PCI-regulated environment, the stakes are even higher — you can't afford to rush a migration that touches systems handling payment card data.

This is where HeroDevs Never-Ending Support (NES) comes in, and why it's particularly relevant under PCI DSS 4.0.

NES provides commercial long-term support for open source software that has reached end-of-life. HeroDevs engineers maintain the EOL codebases, backport security fixes, and publish patched releases as drop-in compatible packages through standard registries (npm, Maven, PyPI). No architectural changes required.

‍

How NES Changes the PCI DSS Impact

Here's the key insight: PCI DSS 4.0's Requirement 12.3.4 triggers when software is no longer receiving security fixes from its vendor. When HeroDevs provides NES for an EOL component, that condition is no longer met. The software now has an active vendor providing security patches and support.

This changes the compliance picture in several meaningful ways. The documented remediation plan required under Requirement 12.3.4 can reflect active vendor support rather than an open gap. Critical patches are available and can be applied within the 30-day window required by Requirement 6.3.3. The software inventory required under Requirement 6.3.2 shows a supported component rather than an unsupported one. The compliance and security teams receive a contractual commitment to patch critical vulnerabilities, with the release history and audit trail to prove it. And the audit surface shrinks — your assessor sees a supported component with a patching track record, not a compliance gap waiting to be flagged.

‍

Common Questions

Does PCI DSS only apply to banks?

No. PCI DSS applies to any organization that stores, processes, or transmits payment card data. That includes banks and payment card issuers, but also merchants and retailers that accept card payments, payment processors and gateways, and any company that builds or operates software that touches payment card data. If your checkout page, payment API, or backend processing system handles card numbers, PCI DSS applies to you.

My EOL dependency is deep in the stack. Does it still count?

If it's within your payment card data environment, yes. Requirement 12.3.4 doesn't distinguish between a front-end framework and a deep infrastructure library. If it's reached end-of-life, is no longer receiving security updates, and is part of your CDE or connected systems, it falls under the requirement. PCI assessors look at the full in-scope technology stack, not just the components that directly handle payment card data.

We're planning a migration. Are we exempt?

No. Until the migration is complete, the EOL software is still subject in full to Requirement 12.3.4 and Requirement 6.3.3. In fact, having a documented migration plan is part of complying with Requirement 12.3.4 — but the plan alone doesn't close the gap. You still need to demonstrate that vulnerabilities are being addressed in the interim. NES is useful precisely in this scenario: it bridges the gap between "we know we need to migrate" and "the migration is done," keeping your patching obligations met while your engineering team does the work properly and on its own timeline.

Can we use compensating controls instead?

Technically, yes, but this would be deemed to be 'kicking the can down the road' in delaying addressing your PCI DSS problem — NES will directly address your PCI DSS problem in a cost effective manner. PCI DSS does allow compensating controls for organizations with documented technical or business constraints that prevent meeting a requirement. Compensating controls require extensive documentation, must be reviewed and validated by your QSA at every assessment, and typically cost more over time than addressing the root issue. NES eliminates the need for compensating controls entirely — the software is supported, so the standard requirement is met directly.

What happened to companies that failed to patch EOL software?

The most cited example is Equifax in 2017. An unpatched vulnerability in Apache Struts (CVE-2017-5638) led to a breach exposing 147 million consumer records, resulting in a $700 million+ settlement. While Equifax's case involved multiple regulatory frameworks, it is widely cited in PCI compliance case studies as a cautionary example of what happens when known vulnerabilities in outdated software components go unaddressed. The Heartland Payment Systems breach in 2008 is another frequently referenced case — attackers exploited a web login page that had been deployed eight years earlier without updates, the kind of legacy component that Requirement 12.3.4 now specifically targets. The total cost to Heartland exceeded $200 million.

‍

The Bottom Line

PCI DSS 4.0's Requirement 12.3.4 is now fully enforceable. It maps directly to end-of-life open source software, which is to say that if a component within your stack is no longer receiving security fixes, you have a documented compliance obligation that requires senior management approval to address. Combined with the patching timeline under Requirement 6.3.3, EOL software in a payment card data environment is a compliance gap that assessors will flag.

If your organization processes payments and your in-scope systems include EOL dependencies — and nearly all stacks do — the question isn't whether this is a risk. It is. The question is what to do about it. HeroDevs Never-Ending Support is one of the most cost-effective and assured ways to close the gap: restore active vendor support, get critical vulnerabilities patched within PCI timelines, and give your compliance team something defensible to show assessors.

Start by checking what's in your stack. The HeroDevs End of Life Dataset is a free resource that tracks 12 million+ package versions and enables enterprises to see which EOL frameworks have known, unpatched CVEs, and what NES support is available for them.