Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Express 4 has been in maintenance since April 2025, with EOL targeted from October 2026.
- Only the newest release in a major line gets fixes, so pinned 4.x minors are not covered.
- Express 3 left support in July 2015, and nothing in it has been fixed since that August.
- Express 5 requires Node.js 18 or later, so a framework upgrade often becomes a runtime migration.
Express earned its reputation by doing very little. Minimalist routing, a middleware pipeline, and just enough convention to stop teams arguing about folder structure. That restraint is exactly why so many services ended up on Express without anyone making a deliberate decision about it, and why nobody goes back to look once the thing works.
That is how a payments API ends up running Express 4.17.1 untouched for seven years, until a dependency scanner flags it. Nothing happened in the code. What changed is everything around it.
The contradiction sits in two statements. The Express website tells you the 4.x line still has ongoing support. Your dependency scanner tells you the service is vulnerable. Both are correct at the same time, because support for the 4.x line is not the same thing as support for every historical 4.x release.
That is not negligence. That is longevity. The 2026 Verizon DBIR found that exploitation of vulnerabilities is now the most common way breaches begin, at 31 percent of initial access, up from 20 percent the year before and ahead of credential abuse for the first time in the report’s 19-year run. Median time to full remediation stretched from 32 days to 43 over the same period. Vulnerable systems tend to be the ones working well enough that nobody feels any urgency about them.
Is Express 4 end of life?
Short answer: no. Express 4 is not EOL as of August 2026, and the 4.x line is still shipping releases. The longer answer is that the clock is running now, and that the major version tells you nothing about whether the release pinned in your lockfile is getting fixes.
For most of its life Express had no LTS calendar at all. That changed in March 2025, when the project published an LTS strategy alongside making 5.1.0 the npm default. Majors now move through CURRENT, ACTIVE, and MAINTENANCE phases. Express 4 entered MAINTENANCE on April 1, 2025, meaning security patches and high priority bug fixes only, with EOL targeted for no sooner than October 1, 2026. The project calls these goals rather than commitments and flags v4 as a special case that may get extended, but the direction is not ambiguous.
Meanwhile the official version support page still lists 4.x and 5.x as “ongoing” with no end date, next to a minimum Node.js version and a support start date for each major. The two documents do not say the same thing, which is an awkward answer to hand an auditor asking when your framework stops being supported.
The rule that actually matters is one line at the top of that support page. Only the latest version of any given major release line is supported. The security updates page then walks through which vulnerabilities were fixed in which release, version by version. Read together, these say something the version number alone does not: being on a supported major is not the same as being on a supported version.
| Express version | Support status | Latest release | Key dates |
|---|---|---|---|
| Express 3.x | End of life | 3.21.2 | Support ended July 2015, with nothing addressed since August 1, 2015 |
| Express 4.x | Maintenance since April 1, 2025 | 4.22.2 | Released May 11, 2026; EOL targeted no sooner than October 1, 2026 |
| Express 5.x | Active since March 31, 2025 | 5.2.1 | 5.0.0 released September 9, 2024; 5.x became the npm default with 5.1.0 |
That distinction is what closes an audit finding or leaves it open. The fact that 4.x is alive tells you nothing about 4.17.1, because fixes land on the newest 4.x rather than on whatever minor got pinned back in 2019. If you cannot name the exact version in your lockfile, you do not yet know whether you are supported. Go find it before you argue with the scanner.
The middleware time capsule
Express itself is small. What makes an old Express service fragile is everything bolted onto it – body parsers, session stores, authentication strategies, template engines, and custom middleware written years ago by people who have since left and documented none of it.
Updating Express alone creates a false sense that the problem is handled. Upgrade the framework, watch the top-level advisory clear, and a vulnerable transitive package can still be sitting a level below, untouched.
Express 4 declares roughly 30 direct dependencies, including qs, body-parser, send, serve-static, path-to-regexp, proxy-addr, and forwarded, with a larger resolved tree underneath them. Nobody picked those libraries. They arrive with Express, and a vulnerability in one of them becomes a vulnerability in your application whenever the affected code path is reachable. Four CVEs from 2024 show how that plays out.
| CVE | Issue | Reaches Express through | Fixed in |
|---|---|---|---|
| CVE-2024-29041 | Open redirect via res.location() and res.redirect() |
Express core | 4.19.2 |
| CVE-2024-43796 | XSS via res.redirect() |
Express core | 4.20.0 |
| CVE-2024-45296 | ReDoS in path-to-regexp | path-to-regexp dependency | 4.20.0 |
| CVE-2024-52798 | Second ReDoS in path-to-regexp | path-to-regexp dependency | 4.21.2 |
The awkward part is that 4.19.2 is the release that fixed the open redirect, and it still predates everything after it. An application sitting on 4.19.2 has cleared CVE-2024-29041 and carries the XSS and both path-to-regexp ReDoS issues, because those fixes landed further along the 4.x line. Worth noting too that the open redirect took three attempts, with an initial fix in 4.19.0, a regression patched in 4.19.1, and the bypass properly handled in 4.19.2, so anything short of 4.19.2 is not fully patched for that issue.
Warning: Before you triage, run npm ls path-to-regexp qs send against the dependency tree your application actually ships, and compare the resolved versions against your lockfile. A transitively pinned copy pulled in by some other dependency can leave you exposed even when Express itself is current.
One caveat is worth keeping in view. “Affected” is not “exploited.” Whether a finding is an incident or a line item comes down to whether your application actually exposes the vulnerable code path to attacker-controlled input.
That gap is what vendor patching for open source is meant to close. TuxCare’s coverage for Express extends across the supported components that ship alongside a covered release rather than the top-level express package alone, which is the difference between remediating a finding and deferring it. Research from Endor Labs estimates that roughly 95 percent of open source vulnerabilities sit in transitive dependencies rather than in the ones developers chose directly, and a legacy deployment rarely has the option of simply moving to whichever branch the fix landed on. TuxCare’s CVE tracker shows patch status per version, so you can see which side of that line you are on.
Express 5 brings Node.js along with it
The part that gets left out when “upgrade to Express 5” goes into a budget is that Express 5 requires Node.js 18 or later. A framework upgrade turns into a runtime migration with a framework upgrade attached to it.
Express 5 also changed behaviors that older applications quietly leaned on. Rejected promises and errors thrown by async handlers now get forwarded to error-handling middleware automatically. A batch of deprecated signatures is gone, including res.send(body, status) and the “back” magic string in res.redirect. Route matching moved to path-to-regexp 8, which dropped sub-expression regular expressions in path strings as a ReDoS mitigation, so routes relying on those patterns need rewriting.
Picture an internal claims service still standardized on a Node 14 era container image. Express 4 to 5 is the easy part. The hard part is moving that image onto a currently supported Node.js release, which clears the Express 5 minimum anyway, without breaking native modules compiled against the older ABI.
Express’s own migration guide is upfront that a v4 application may not run unchanged on v5, and that framing is useful. It makes this a runtime and testing problem before it is a framework problem.
Expert Advice: Before upgrading Express, run your existing test suite against the Node.js release you actually plan to deploy. Something as plain as nvm use <target> && npm test will surface native-module and ABI failures that have nothing to do with Express.
Three realistic paths and what each costs
There is no universal answer here, only the one that fits your dependency graph, your test coverage, and your runtime. Three paths cover most situations.
Move to Express 5
This is the option when the dependency tree is clean and the integration tests are worth trusting. Upgrade the runtime, upgrade Express, work through async error handling and route patterns, and watch CI go green. The framework change can easily be the smaller half of the job.
Stay on 4.x and track the newest release
Defensible for applications that stick to conventional routing and mainstream middleware, though the runway is shortening. Follow the latest 4.x, currently 4.22.2, and treat that as routine rather than a one-off. It is not free either. On December 1, 2025, Express shipped a query parser change on both live lines for what had been filed as CVE-2024-51999. The CVE was then rejected as not a vulnerability, and 4.22.1 and 5.2.1 reverted the change the same evening, roughly four hours after the originals went out. Even that did not close it, since 4.22.2 in May 2026 had to restore array parsing behavior for repeated query keys. Staying current means absorbing that. Sitting on a supported major only helps while you keep moving with the line, and the moment you freeze on an older 4.x you are back in the same position as anything pinned to 4.17.1.
Extended support while the migration gets scheduled
That leaves the cases the first two do not cover – a frozen Node.js runtime, custom authentication middleware, or a migration that genuinely runs into quarters. A regulated API with a bespoke auth layer and a pinned runtime can easily need more than a sprint or two, and rushing it because a scanner turned red is how outages happen. TuxCare ELS covers specific Express releases, including 3.4.8, 3.21.2, 4.17.1, 4.18.1, 4.18.2, 4.18.3, and 4.19.2, distributed as scoped @els-js packages through an authenticated TuxCare registry.
| Path | Best fit | Typical effort |
|---|---|---|
| Move to Express 5 | Clean deps, tests you trust | Mostly the Node.js jump and the testing behind it |
| Track newest 4.x | Routing plus standard middleware | Ongoing, and the runway is shortening |
| Extended support (ELS) | Frozen runtime, bespoke middleware | A bridge while migration takes quarters |
The short version. A clean graph and tests you believe in point to Express 5. Conventional routing and standard middleware point to tracking the newest 4.x and staying there. A frozen runtime or a multi-quarter migration points to extended support that is planned rather than open-ended, which matters more now that 4.x has a target EOL date attached to it.
How TuxCare supports out-of-support Express
Extended support for a library is not glamorous work, and that is rather the point. It starts with vulnerability monitoring across the covered Express release and the supported components that ship with it. The first question on any new disclosure is whether it actually affects that release, or whether it only touches code paths introduced later.
When a patch is needed, the approach is disciplined backporting. Take the security-relevant change from the upstream fix, leave behind the unrelated refactoring that shipped with it, and avoid dragging in a framework upgrade nobody planned for. The result gets regression-tested against the legacy behavior before it goes out as a maintained package, with SBOM and VEX data published alongside it. That machine-readable evidence is what lets a security team document a finding properly instead of pushing it to next quarter. This is specialization rather than a replacement for upstream, which means long-term maintenance of branches the project has already moved past, with compatibility testing before anything ships.
Compliance teams always ask about timing, so here are the published targets. High and critical vulnerabilities, meaning CVSS 7.0 and above, carry a target response time of 14 days from public disclosure, medium vulnerabilities 60 days, and low vulnerabilities 90. Covered versions and installation steps live in the TuxCare ELS for Express documentation, with the wider picture under library EOL support.
Where OpenJS sustainability fits
Express is an Impact Project under the OpenJS Foundation, and that matters because the Foundation provides an official framework for commercial support of archived, end-of-life, and older project versions. The OpenJS Ecosystem Sustainability Program launched in May 2024 to connect commercial providers with those versions, with partners returning a share of enterprise revenue to the participating projects.
TuxCare is listed as an ESP partner alongside HeroDevs and NodeSource, and the program requires partners to be Gold or Platinum members of the Foundation. The Node.js end-of-life page names the same three providers, which is a fair signal that this is an established model rather than an improvisation.
Two boundaries are worth stating plainly. The program is non-exclusive and open to any provider meeting the requirements, and it does not stop maintainers from publishing public fixes for any version, including versions an ESP partner covers. It is also worth knowing that the Express project’s own support page currently lists HeroDevs as its commercial option, so coverage for your specific version is something to confirm directly with whichever provider you evaluate.
Reality Check: A vendor backport can remediate covered vulnerabilities in 4.17.1, but it does not make 4.17.1 an upstream-supported release. If a compliance requirement specifically says upstream support, the vendor patch is answering a different question, and it pays to know which one you are being asked.
How to assess an old Express application
Before picking a path, work out where you actually stand. Start with the exact Express version in your lockfile rather than the range in package.json. Walk the direct and transitive dependencies with npm ls and check them against known advisories. Inventory the custom middleware and any undocumented behavior the application leans on. Establish which Node.js version the application runs and whether that runtime is still supported, because that decides whether Express 5 is even on the table. Then weight all of it by exposure and business criticality, so the payments API gets attention ahead of a low-traffic internal dashboard.
One thing is easy to miss. Express can also arrive transitively through SDKs, middleware packages, and other dependencies, so versions nobody chose to install still show up in the graph. An assessment that skips lifecycle status and indirect dependencies produces a list rather than a picture.
Upgrade on an architectural timeline, not because a disclosure forced the schedule. Endless Lifecycle Support exists to buy that room, keeping the running version patched while the migration happens on a schedule you can test and control.
