HeroDevs Announces Never-Ending Support (NES) for React

React is the most widely adopted frontend library in the world. Roughly 44% of developers use React, making it the most used frontend framework according to the 2025 Stack Overflow Developer Survey, and legacy versions remain deeply embedded in production: npm download data shows React 16 still sees roughly 3.5 million downloads per week, and React 17 roughly 3.6 million, years after active development moved on. Those numbers tell a clear story. A substantial population of  enterprise frontends run on legacy React versions that may receive limited upstream security fixes.

Today, HeroDevs is announcing the availability of Never-Ending Support (NES) for React, covering React 16.x and 17.x. NES for React delivers ongoing vulnerability remediation for react and react-dom, across all severity levels, as a drop-in npm replacement with zero application code changes required.

‍

Understanding the Support Gap

Unlike Node.js or Angular, React has no formal long-term support (LTS) program and no published end-of-life dates. The project's versioning policy states that security fixes are backported to affected major versions, but that commitment is discretionary in scope, covers no defined severity range, and carries no response timelines.

With React 19 now the current major version, React 16 and React 17 sit well outside active development. Applications built on them continue to render and function in production. That is precisely what makes the risk easy to overlook: "it still works" is not the same as "it is secured and supported.”

‍

The Intersection of EOL Open Source Software and Compliance

Because React is bundled into JavaScript-based applications, an unpatched vulnerability in a legacy React version ships with every application still running it. And unsupported open source software is not only a security concern, it is a compliance gap that auditors increasingly treat as a finding.

Standards and regulations including SOC 2, PCI DSS v4.0, HIPAA, FedRAMP, DORA, and the EU's NIS2 directive require, directly or through their risk management provisions, that software components remain under active support and that known vulnerabilities are remediated within defined timelines. A Software Bill of Materials (SBOM) that surfaces a legacy React version with unpatched CVEs triggers red flags in automated audits, and an open finding with no remediation path is difficult to defend to an auditor, a customer security review, or a regulator.

‍

HeroDevs NES for React: Closing the Gap

HeroDevs Never-Ending Support provides a safety net for end-of-life open source software. Our team monitors for newly disclosed CVEs, proactively researches vulnerabilities in the codebases we support, publishes findings in the HeroDevs Vulnerability Directory, and delivers remediated packages through a secure private registry. As an authorized CVE Numbering Authority (CNA), HeroDevs identifies, resolves, and discloses vulnerabilities in open source software directly.

NES for React extends this model to the React ecosystem:

• CVE fixes for React 16.x and 17.x: vulnerability remediation for react and react-dom across all severity levels, not just Critical issues.
• SLA commitments: contractual remediation timelines mapped to severity, replacing best-effort community goodwill.
• Drop-in installation: a simple npm registry swap with no code changes and no application refactoring.
• Compliance alignment: a named vendor, committed SLAs, and a documented patch history that satisfy scanner findings and auditor questions about unsupported dependencies.

‍

Why is Upgrading to React 18 and 19 So Hard?

Upgrading to the latest React version remains the long-term best practice, and NES is a bridge to that modernization, not a replacement for it. But for enterprise-grade applications, the upgrade is rarely immediate:

• Behavioral changes: React 18 introduced new rendering behavior, including concurrent features and automatic batching, that can change how existing components behave. Large codebases often require months of coding and QA to migrate safely.
• Ecosystem dependencies: older React applications frequently depend on component libraries and build tooling that have their own upgrade constraints, and some have no direct upgrade path at all.
• Cost and opportunity cost: in HeroDevs' experience working with enterprise teams, migrating a single codebase commonly runs $50K to $250K with 1 to 3 months of regression testing per application. Organizations running dozens or hundreds of React applications cannot migrate them all overnight, and every migration sprint is capacity pulled from the product roadmap.

NES for React buys back that time. Teams remediate the security and compliance exposure now, then sequence migrations by business priorities.

‍

Security Risk of Legacy React

Prior to version 19, React maintained a notably low CVE record, and it would be misleading  to suggest otherwise. Then, in December 2025, CVE-2025-55182, a critical (CVSS 10.0) unauthenticated remote code execution vulnerability in React 19 Server Components, drew emergency advisories from major cloud and CDN providers, and landed on CISA's Known Exploited Vulnerabilities list within 48 hours, demonstrating that even mature, heavily scrutinized frontend ecosystems can suffer severe vulnerabilities. We covered that incident and what it reveals about open source risk in When Lightning Strikes Twice: What React/Next.js' Critical RCE Reveals About Open-Source Risk. Meanwhile, AI-assisted vulnerability discovery is accelerating disclosure volume across the industry: a record 48,185 CVEs were published in 2025, a 20.6% increase over 2024 and more are being discovered in 2026.

A quiet security history is not a guarantee of future safety, especially now with AI vulnerability discovery assistance. For React 16 and 17, the practical question is simple: when the next vulnerability affecting these versions is disclosed, do you receive a patch? With NES for React, the answer is yes, HeroDevs makes a patch available under SLA timeframes.

‍

One Vendor for Your JavaScript Stack

NES for React joins an established HeroDevs JavaScript portfolio, so organizations can consolidate their frontend and backend legacy estate under a single vendor, contract, and SLA. If your React applications run on end-of-life versions of Next.js, see our companion guide to Next.js EOL dates and version support timelines for how the two lifecycles intersect.

‍

Taking Action

If your organization runs React 16 or React 17 in production and cannot migrate immediately, the next React CVE won't wait for your migration roadmap. You do not have to choose between an unplanned migration and unpatched vulnerabilities. NES for React keeps your applications secure, compliant, and operational for as long as you need, while you modernize on your own timeline.

Contact the HeroDevs team to secure your React applications, or get a custom quote to bundle React with Next.js, Node.js, and Express under one contract.

‍

Frequently Asked Questions

1. Which React versions does NES for React cover?

NES for React covers React 16.x and 17.x, including the react and react-dom packages. Coverage includes vulnerability remediation across all CVE severity levels, delivered under contractual SLAs.

2. Does React have official end-of-life dates?

No. The React project does not publish formal EOL dates or maintain an LTS program. Active development and fixes go to the latest major version. Older versions may receive critical fixes at the community's discretion, but there is no official commitment, defined scope, or response timeline.

3. Will installing NES for React require code changes?

No. NES for React is a drop-in replacement installed through your existing npm workflow. You point your registry configuration at the secure NES registry, update your dependency entries, and run npm install. Your application code, build pipeline, and tests remain unchanged.