# A New Chapter for Express.js: Triumphs of 2024 and an ambitious 2025 and more

# A New Chapter for Express.js: Triumphs of 2024 and an ambitious 2025

> Explore the transformative journey of Express.js in 2024, marked by governance improvements, the long-awaited release of Express 5.0, and heightened security measures. Look into the ambitious plans for 2025, including performance optimizations, scoped packages, and a bold roadmap for sustained growth in the Node.js ecosystem.

# A New Chapter for Express.js: Triumphs of 2024 and an ambitious 2025

    By

        [Express Technical Committee](https://github.com/expressjs)  09 Jan 2025

As we step into the new year, it’s almost impossible to ignore the unmistakable energy coursing through the Express.js community. The past twelve months have proven both foundational and forward-looking: an era of governance overhauls, technical triumphs, and security enhancements that not only shaped 2024 but also laid the groundwork for what promises to be a transformative 2025.
In this long-form recap and forecast, we’ll journey through the story of Express.js with its evolution, its hurdles, and the new heights it’s poised to reach.

---

## A Transformative 2024

Few could have predicted just how pivotal 2024 would be for the Express.js project. From the revitalization of its governance structures to the unveiling of long-awaited features, it was a year that solidified the framework’s role as a mainstay in the Node.js ecosystem.

### Governance and Community Milestones

Central to the project’s growth was the [Express Forward Plan](https://github.com/expressjs/discussions/issues/160), devised to ensure strategic alignment and long-term sustainability. This year also saw the introduction of a new generation of Technical Committee (TC) members, each bringing fresh insights and energy to the community. Those members include [Blake Embrey](https://github.com/blakeembrey), [Chris de Almeida](https://github.com/ctcpip), [Jean Burellier](https://github.com/sheplu), [Jon Church](https://github.com/jonchurch), [Linus Unnebäck](https://github.com/LinusU), [Rand McKinney](https://github.com/crandmck), [Ulises Gascón](https://github.com/ulisesgascon), and [Wes Todd](https://github.com/wesleytodd). By defining a clear path and transparent processes, the community was able to collaborate on ambitious updates more cohesively than ever before. A revitalized release process further streamlined how new versions are planned and executed, eliminating much of the guesswork and inconsistent timing that had previously challenged contributors.

In parallel, the [Security Working Group](https://github.com/expressjs/discussions/issues/165) took shape. Express.js, widely recognized for its importance to the broader Node.js landscape, formally introduced a [security triage team](https://github.com/expressjs/security-wg#security-triage-team) dedicated to proactively identifying and resolving vulnerabilities. This forward-thinking approach was bolstered by the adoption of a [Threat Model for Express.js](https://github.com/expressjs/express/pull/5526), underscoring the project’s commitment to robust, future-proof security.

As if these achievements weren’t enough, Express.js proudly reached [Impact Project status](https://github.com/openjs-foundation/cross-project-council/pull/1404) under the OpenJS Foundation. This acknowledgment affirmed the significance of the framework to the JavaScript ecosystem and showcased the community’s tireless efforts in ensuring its enduring relevance.

### Technical Advancements and the Release of Express 5.0

Naturally, 2024 will forever be remembered as the year when Express.js finally introduced its much-anticipated [Express 5.0](https://expressjs.com/2024/10/15/v5-release.html). After more than a decade of community discussions and behind-the-scenes experimentation, this release brought modern features and a future-oriented architecture to the framework, acting as a catalyst for the next chapter of Express.js development.

But the story did not end there. Even before the release of Express 5.0 was fully established, the community had already begun charting the course for [Express 6.0](https://github.com/expressjs/discussions/issues/267), reflecting an unwavering commitment to innovation. Guiding critical decisions throughout 2024 were new [decision framework](https://github.com/expressjs/discussions/issues/285), which helped the Technical Committee tackle pressing matters such as [engine usage](https://github.com/expressjs/discussions/issues/286) and [dependency management](https://github.com/expressjs/discussions/issues/279). Collectively, these measures fostered transparency and agility, ensuring that Express.js continues to evolve in response to the community’s most urgent needs.

### Maintenance, Tooling, and Collaboration

Express.js also deepened its relationship with the Node.js community by re-integrating into the [Node.js CITGM project](https://github.com/expressjs/express/issues/5489). This move ensured broader ecosystem compatibility and provided developers with further validation that they can rely on Express.js as a dependable cornerstone of their Node.js applications.

### A Heightened Security Posture

Above all, 2024 will stand out for Express.js’s vigorous approach to security. In partnership with the [OpenJS Foundation](https://openjsf.org/) and [OSTIF](https://ostif.org/), the project undertook a comprehensive [security audit](https://expressjs.com/2024/10/22/security-audit-milestone-achievement.html) that yielded critical insights and propelled immediate improvements. The sense of proactive vigilance extended to the adoption of the [OSSF Scorecard](https://github.com/expressjs/discussions/issues/162), implemented at an organizational level to keep track of security metrics and maintain focus on ongoing enhancements.

Throughout the year, maintainers rapidly responded to disclosed vulnerabilities such as [CVE-2024-43796](https://github.com/expressjs/express/security/advisories/GHSA-qw6h-vgh9-j6wx), [CVE-2024-45590](https://github.com/expressjs/body-parser/security/advisories/GHSA-qwcr-r2fm-qrc7), and [CVE-2024-47178](https://github.com/expressjs/basic-auth-connect/security/advisories/GHSA-7p89-p6hx-q4fw). Each instance underscored the community’s readiness to defend the framework’s integrity and safeguard its user base. In a further demonstration of long-term commitment, Express.js teamed up with [HeroDevs](https://www.herodevs.com/) to establish [Never-Ending Support (NES)](https://openjsf.org/blog/at-the-openjs-foundation-were-excited-to-announce-), offering an extended maintenance plan that reaffirms Express.js as a reliable foundation for developers now and in the years to come.

---

## A Bold Vision for 2025

While 2024 laid a sturdy bedrock, the Express.js Technical Committee is not resting on its laurels. The newly revealed roadmap for 2025—bolstered by the [Sovereign Tech Fund (STF)](https://www.sovereign.tech/)—embodies a spirit of forward momentum. It promises notable strides in security, performance, and general developer experience, with each initiative building on the insights gained over the past year.

### Automating npm Releases

At the forefront of this plan is the automation of npm releases, an endeavor designed to free maintainers from manual steps and human error. By streamlining the publishing process, the project can achieve faster turnaround times for patches and new features, preserving the stability that developers have come to expect from Express.js. It’s an internal shift with massive external benefits: smoother upgrades, more frequent releases, and a deeper reservoir of confidence for users.

### Introducing Scoped Packages

Express.js will also explore a transition toward scoped packages. By clearly delineating which modules fall under the Express.js umbrella, the maintainers hope to reduce confusion and foster an environment more conducive to organized expansion. As new packages and features are proposed, scoping will make it simpler to track official tools and ensure that community contributions meet consistent quality standards.

### Strengthening Security Reporting and Procedures

Since security remains one of the project’s primary pillars, 2025 will see a significant push to refine how vulnerabilities are reported and managed. Building upon the success of the Security Working Group, the new process will introduce transparent guidelines for reporting potential issues and a consistent triage routine for mitigating them. Additional training for both the Security Triage group and the Technical Committee will further cultivate a shared culture of readiness. Moreover, Express.js is poised to integrate [OSSF Scorecard](https://github.com/expressjs/discussions/issues/162) even more deeply into daily operations, ensuring that both maintainers and users have real-time insights into the project’s health.

### Performance Monitoring and Deep-Level Optimizations

Performance is another focal point. By systematically monitoring the framework’s speed and responsiveness—along with that of its dependencies—the Express.js team aims to pinpoint bottlenecks more rapidly. Over time, insights from these monitoring efforts will drive deeper optimizations in the core Express.js code and its core libraries. These improvements, expected to come to fruition by mid-2026, promise a faster, more scalable framework that can handle the heaviest production workloads with ease.

### Phasing Out Legacy Techniques and Enhancing Documentation

A future of agility and resilience depends on eliminating outdated techniques that invite complexity and fragility. As a result, Express.js will begin phasing out monkey-patching and passthrough APIs that rely too heavily on Node.js internals. This modernization strategy not only reduces technical debt but also ensures that Express.js remains aligned with Node.js updates going forward.

In tandem, the project will make a concerted effort to bolster its security documentation. Through updated guides and best practices, maintainers hope to demystify crucial topics like secure session handling, input validation, and access control. The goal is to arm developers—from novices to seasoned engineers—with the knowledge they need to protect their applications against an ever-evolving threat landscape.

---

## The Road Ahead

As Express.js steps into 2025, it does so with a powerful sense of purpose. The achievements of the past year—culminating in the official release of Express 5.0 and wide-reaching governance enhancements—serve as a sturdy foundation for what’s to come. Yet, the framework’s leadership knows there is always more to build, more to secure, and more to imagine.

Through automated releases, scopes for packages, rigorous security protocols, performance monitoring, and an ongoing effort to modernize core APIs, Express.js is evolving in real-time. And it isn’t just about technology; it’s about forging a collaborative environment where contributors can rely on transparent processes, robust training, and a supportive governance structure.

Whether you’re a seasoned maintainer, an occasional contributor, or a newcomer to this thriving ecosystem, your voice matters. Join the [Express.js GitHub Discussions](https://github.com/expressjs/discussions), attend open meetings, and stay tuned for updates on [Express.js blog](https://expressjs.com/) as we finalize timetables for these initiatives. Each advancement, no matter how technical, flows from a common aspiration: to sustain Express.js as a fast, safe, and influential framework for millions of developers worldwide.
Together, we’ll keep the spirit of 2024 alive—pushing boundaries, refining practices, and laying the path to a future where Express.js remains at the heart of modern web development.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-01-09-rewind-2024-triumphs-and-2025-vision.md          )

---

# [email protected]: Now the Default on npm with LTS Timeline

> Express 5.1.0 is now the default on npm, and we're introducing an official LTS schedule for the v4 and v5 release lines.

# [email protected]: Now the Default on npm with LTS Timeline

    By

        [Express Technical Committee](https://github.com/expressjs)  31 Mar 2025

Express v5.0.0 was released on September 9th last year, but we didn’t make it the `latest` release on npm. Many asked us
why and when it would be, and frankly we were not ready at the time to take that jump. If you have not followed the news
from the project this past year, we have been [hard at work reviving the project](https://expressjs.com/2025/01/09/rewind-2024-triumphs-and-2025-vision.html)
and when we pushed the initial v5 release there were many loose ends still hanging. So first lets quickly go over some
of those loose ends.

### Documentation updates

We had not updated the docs, provided migration guides, or even fully reviewed some of the stagnated v4/5 docs in a long
time. Since then we have had tons of great contributors help get things into better shape. As with any volunteer based
Open Source project, we love contributions to help us improve so as you upgrade please continue to open PRs to fix
anything we missed.

You can find our [v5 docs](https://expressjs.com/en/5x/api.html) and our [migration guide](https://expressjs.com/en/guide/migrating-5.html) on the website.

### Migration Support

We know that migrating between versions can be challenging, especially when it involves significant changes in a widely used framework like Express. That’s why we have worked on a solution to simplify part of the process and reduce the impact on developers.

Thanks to the incredible efforts of [Sebastian](https://github.com/bjohansebas) and [Filip](https://github.com/kjugi), we have developed a new [codemod package](https://www.npmjs.com/package/@expressjs/codemod) specifically designed to facilitate the transition from Express v4 to v5, as well as future major versions. This package automates many of the necessary code changes, minimizing manual effort and making the upgrade as smooth and efficient as possible.

However, we understand that not all changes can be automated. Some breaking changes, such as the [new Path Route Matching syntax](https://expressjs.com/en/guide/migrating-5.html#path-syntax), require manual modifications by developers.  You can read more about all of the breaking changes which came with v5 in our [original release announcement](https://expressjs.com/2024/10/15/v5-release.html).

For more details on the migration process and how to use the codemod package, check the [repository’s README](https://github.com/expressjs/codemod#readme) and the [migration guide](https://expressjs.com/en/guide/migrating-5.html).

### Ecosystem compatibility

The Express ecosystem is one of its strongest assets. It goes back to the early days of Node.js and is the backbone
that keeps express popular. When it goes [10 years without a major release](https://expressjs.com/2024/10/15/v5-release.html)
everything from middleware to documentation needed updates. We wanted to make sure folks had
some time to get all of that updated before we had everyone moving over. Particularly we care about our very large
beginner user base who may not know the blog post they are reading is not compatible with what they get from
`npm i express`.

We recognize that some friction is inevitable during major upgrades, but thanks to work from ecosystem partners
like [Kamil](https://github.com/kamilmysliwiec) from NestJS [working to updateexpressbefore we wentlatest](https://github.com/expressjs/express/issues/5944#issuecomment-2523074127)
we will hopefully be ahead of the curve. And as I said above, we always welcome help to make this transition easier for
those who follow after you, PRs are the best support you can give.

### Long Term Support

We had been discussing how to support v4 now that v5 was out, but we had not defined a clear guideline or expectation,
and we had (still don’t have) end user docs on our plans here. While we still have progress to make here, we have a
[proposed LTS strategy](https://github.com/expressjs/discussions/pull/352) which will be the basis for our forthcoming
docs. Input is very welcome on this so we can make sure it is clearly communicated and acceptable to the community.

Additionally since then [we have announced a partnership with HeroDevs](https://expressjs.com/2024/10/01/HeroDevs-partnership-announcement.html) to help companies who are less capable of
updating. More information on how this will work when v4 EOL will come when we get closer to that time.

---

## Support Phases and Going latest

What does it mean to “go latest”? If you are unfamiliar with how npm `dist-tags` work, the `latest` tag is what users
will get when they run `npm install express`. This is important because it means it is the “default installed version”
and will trigger the transition of nearly 17 million weekly downloads from our current latest v4.21.2 to v5. As we start
this transition we want users, companies, and other organizations to know exactly what it means for support. To help
with this we have developed an LTS strategy which defines our 3 support phases and set’s target dates for when v4 will
enter EOL.

Express major versions will go through three supported phases:

- `CURRENT`: A new major version is designated as `CURRENT` upon release. It is available but not the `latest` version
  on npm for a minimum of 3 months.
- `ACTIVE`: After the minimum 3 month period and the TC agrees it is stable and secure, the `ACTIVE` version is
  tagged `latest` on npm for a minimum of 12 months.
- `MAINTENANCE`: When a new major version becomes `ACTIVE`, the previous major version enters `MAINTENANCE` for 12 months.

### CURRENT

- New majors will go through a short period of hardening to ensure stability, security, and ecosystem libraries/resources
  compatibility.
- We will strive to ensure no breaking changes are included, but reserve the right to make security or high priority
  fixes of breaking nature within this period.
- `CURRENT` lines will receive all types of active work including: bug fixes, security patches, new features, and
  deprecation notices.
- Users are recommended to use  `CURRENT` lines and to upgrade as quickly as their risk profile allows

### ACTIVE

- `ACTIVE` lines will receive all types of active work including: bug fixes, security patches, new features, and
  deprecation notices.
- For users, `ACTIVE` lines are considered the most stable and well supported version at any given time.

### MAINTENANCE

- `MAINTENANCE` lines will only receive security patches or high priority bug fixes.
- Users are highly encouraged to upgrade to a `CURRENT` or `ACTIVE` release.

### Proposed Schedule

For the existing release lines, we will set the following phase dates:

| Major | CURRENT | ACTIVE | MAINTENANCE | EOL |
| --- | --- | --- | --- | --- |
| 4.x |  |  | 2025-04-01 | *no sooner than 2026-10-01 |
| 5.x | 2024-09-11 | 2025-03-31 | **no sooner than 2026-04-01 | **no sooner than 2027-04-01 |
| 6.x | ***no sooner than 2026-01-01 |  |  |  |

As you can see, this means that v5.1.0 being tagged `latest` indicates that we moved from `CURRENT` to `ACTIVE` which
starts the clock on EOL for v4 by moving it to `MAINTENANCE`. We recognize that v4 is a special case having been the
only major version for most of the history of Node.js itself. Because of this, we want to remain flexible and also
provide a bit longer support. We want to do what is best for the ecosystem, so consider these goals not commitments.

*: v4 is a special case, and we may extend MAINTENENCE support

**: v5 MAINTENENCE and EOL dates are determined by when v6 is released, these dates reflect the earliest dates if we
were to ship v6 on 2025-10-01

*** : v6 work has not officially started yet, this is simply the earliest date we can ship based on our proposed policy

---

## Finally, what changed in v5.1.0

This release primarily focused on tech debt from supporting so many old Node.js versions and other things that stagnated but were not landed before v5.0.0 went out.

### Express 5.1.0 Main Changes

- Add support for `Uint8Array` in `res.send()`
- Transitioned all remaining dependencies to use `^` ranges instead of locked versions
- Add package.json funding field to highlight our OpenCollective
- Added support for ETag option in `res.sendFile()`
- Added support for adding multiple links with the same rel with `res.links()`
- Performance: Use loop for acceptParams
- See [Changelog v5.1.0](https://github.com/expressjs/express/releases/tag/v5.1.0)

### Dependencies updated

We also invested time to prepare several releases in the packages that Express depend on. Most of this packages are used by other libraries and framework as individual libraries.

- [[email protected]](https://github.com/expressjs/body-parser/releases/tag/v2.2.0)
  - Remove legacy node.js support checks for Brotli & `AsyncLocalStorage`
  - Remove `unpipe` & `destroy`
- [[email protected]](https://github.com/pillarjs/router/releases/tag/v2.2.0)
  - Restore `debug`. Now with the `router` scope instead of `express`.
  - Remove legacy node.js support checks for `setImmediate`
  - Deprecate non-native promise support
  - Remove `after`, `safe-buffer`, `array-flatten`, `setprotoypeof`, `methods`, `utils-merge`
- [[email protected]](https://github.com/pillarjs/finalhandler/releases/tag/v2.1.0)
  - Remove legacy node.js support checks for `headersSent`, `setImmediate`, & http2 support
  - Remove `unpipe`
- [[email protected]](https://github.com/expressjs/serve-static/releases/tag/v2.2.0)

---

## Thanks and What’s Next

Thanks so much to everyone involved in Express over the past year, the work all our contributors have put in is
incredible, and we couldn’t do it without them. If you are not able to become a contributor yourself, please consider
asking your companies to support the project financially on [OpenCollective](https://opencollective.com/express).

As we look ahead, we’re excited to keep building momentum. If you haven’t read it yet, our [Rewind 2024 + 2025 Vision blog post](https://expressjs.com/2025/01/09/rewind-2024-triumphs-and-2025-vision.html) lays out where we’ve been and where we’re headed. This includes performances scoped packages, better automation, security hardening, and more.

One major initiative is our new [Performance Working Group](https://github.com/expressjs/discussions/pull/306), focused on identifying and fixing long-standing bottlenecks in Express. We’re grateful to be kicking this off with support from the [Sovereign Tech Fund (STF)](https://www.sovereign.tech/), who are helping us invest in long-term sustainability and performance of core infrastructure. Additionally, we will be working to [improve our Typescript DX](https://github.com/expressjs/discussions/issues/192) and taking next steps to [improve the website](https://github.com/expressjs/expressjs.com/issues/1787).

And yes, v6 discussions are already starting to heat up. Keep an eye out for updates, and as always, see you in the issues!

Big thanks to [@wesleytodd](https://github.com/wesleytodd), [@blakeembrey](https://github.com/blakeembrey), [@bjohansebas](https://github.com/bjohansebas), [@UlisesGascon](https://github.com/UlisesGascon), [@Phillip9587](https://github.com/Phillip9587), [@carpasse](https://github.com/carpasse), [@jonchurch](https://github.com/jonchurch), [@ctcpip](https://github.com/ctcpip), [@inigomarquinez](https://github.com/inigomarquinez), [@carlosstenzel](https://github.com/carlosstenzel), [@crandmck](https://github.com/crandmck), [@chrisdel101](https://github.com/chrisdel101), [@dpopp07](https://github.com/dpopp07), [@Ayoub-Mabrouk](https://github.com/Ayoub-Mabrouk), [@jonkoops](https://github.com/jonkoops), [@IamLizu](https://github.com/IamLizu), [@marco-ippolito](https://github.com/marco-ippolito), [@ipreencekmr](https://github.com/ipreencekmr), [@ShubhamOulkar](https://github.com/ShubhamOulkar), [@raksbisht](https://github.com/raksbisht), [@jeffreybaird](https://github.com/jeffreybaird), [@dougwilson](https://github.com/dougwilson), [@mertcanaltin](https://github.com/mertcanaltin), [@GeorgeShvab](https://github.com/GeorgeShvab), [@RobinTail](https://github.com/RobinTail), [@EvanHahn](https://github.com/EvanHahn), [@rhodgkins](https://github.com/rhodgkins), [@cengizcmataraci](https://github.com/cengizcmataraci), [@Shantanugupta43](https://github.com/Shantanugupta43), [@italojs](https://github.com/italojs), [@ljharb](https://github.com/ljharb), [@MaoShizhong](https://github.com/MaoShizhong), [@aroyan](https://github.com/aroyan), [@Binilkks](https://github.com/Binilkks), [@danielgindi](https://github.com/danielgindi), [@papandreou](https://github.com/papandreou), [@jsoref](https://github.com/jsoref), [@bigbigDreamer](https://github.com/bigbigDreamer), [@broofa](https://github.com/broofa), [@CommanderRoot](https://github.com/CommanderRoot), [@andvea](https://github.com/andvea), [@juanarbol](https://github.com/juanarbol), [@agungjati](https://github.com/agungjati), [@alexandercerutti](https://github.com/alexandercerutti), [@pr4j3sh](https://github.com/pr4j3sh), [@hamirmahal](https://github.com/hamirmahal), [@slagiewka](https://github.com/slagiewka), [@Abdel-Monaam-Aouini](https://github.com/Abdel-Monaam-Aouini), [@sazk07](https://github.com/sazk07), [@bhavya3024](https://github.com/bhavya3024), [@joshbuker](https://github.com/joshbuker), [@almic](https://github.com/almic), [@FDrag0n](https://github.com/FDrag0n), [@Dmitry-Kondar](https://github.com/Dmitry-Kondar), [@attrid](https://github.com/attrid), [@kristof-low](https://github.com/kristof-low), [@gireeshpunathil](https://github.com/gireeshpunathil), [@UzairJ99](https://github.com/UzairJ99), [@choi2021](https://github.com/choi2021), [@hayden36](https://github.com/hayden36), [@joharkhan99](https://github.com/joharkhan99), [@peterh-capella](https://github.com/peterh-capella), [@johnburnett](https://github.com/johnburnett), [@nicolasgandrade](https://github.com/nicolasgandrade), [@axhuwastaken](https://github.com/axhuwastaken), [@abhijeetpandit7](https://github.com/abhijeetpandit7), [@peterdanwan](https://github.com/peterdanwan), [@rehmansheikh222](https://github.com/rehmansheikh222), [@corydalis10](https://github.com/corydalis10), [@mgsantos177](https://github.com/mgsantos177), [@wilyJ80](https://github.com/wilyJ80), [@LuiGeeDev](https://github.com/LuiGeeDev), [@juliogarciape](https://github.com/juliogarciape), [@aelmardhi](https://github.com/aelmardhi), [@Ahmed1monm](https://github.com/Ahmed1monm), [@erensarac](https://github.com/erensarac), [@tomasz13nocon](https://github.com/tomasz13nocon), [@tianbuyung](https://github.com/tianbuyung), [@GreyTearsDev](https://github.com/GreyTearsDev), [@aastha-cse](https://github.com/aastha-cse), [@krzysdz](https://github.com/krzysdz), [@Miguelrom](https://github.com/Miguelrom), [@bnoordhuis](https://github.com/bnoordhuis), [@MehfoozurRehman](https://github.com/MehfoozurRehman), [@EasonLin0716](https://github.com/EasonLin0716), [@grjan7](https://github.com/grjan7), [@mishrasur7](https://github.com/mishrasur7), [@gregfenton](https://github.com/gregfenton), [@zareefhasan](https://github.com/zareefhasan), [@Tejas150](https://github.com/Tejas150), [@jpricardo](https://github.com/jpricardo), [@nikeee](https://github.com/nikeee), [@dotnetCarpenter](https://github.com/dotnetCarpenter), [@engpetermwangi](https://github.com/engpetermwangi), [@msimerson](https://github.com/msimerson), [@fetsorn](https://github.com/fetsorn), [@manoharreddyporeddy](https://github.com/manoharreddyporeddy), [@lancatlin](https://github.com/lancatlin), [@mifi](https://github.com/mifi), [@meowingwhitey](https://github.com/meowingwhitey), [@sheplu](https://github.com/sheplu), [@krsriq](https://github.com/krsriq), [@ravibisht](https://github.com/ravibisht), [@wojtekmaj](https://github.com/wojtekmaj), [@aqeelat](https://github.com/aqeelat), [@melikhov-dev](https://github.com/melikhov-dev), [@alexstrat](https://github.com/alexstrat), [@isnifer](https://github.com/isnifer), [@TorstenDittmann](https://github.com/TorstenDittmann), [@Uzlopak](https://github.com/Uzlopak), [@gurgunday](https://github.com/gurgunday), [@kurtextrem](https://github.com/kurtextrem), [@hdtmccallie](https://github.com/hdtmccallie), [@proudparrot2](https://github.com/proudparrot2), [@bewinsnw](https://github.com/bewinsnw), [@jonboulle](https://github.com/jonboulle), [@alexander-akait](https://github.com/alexander-akait), [@alxndrsn](https://github.com/alxndrsn), [@DimitriPapadopoulos](https://github.com/DimitriPapadopoulos), [@greggman](https://github.com/greggman), [@jkbach](https://github.com/jkbach), [@julien-c](https://github.com/julien-c), [@risu729](https://github.com/risu729), [@JohnSimumatik](https://github.com/JohnSimumatik), [@dhouck](https://github.com/dhouck), [@pedro-php](https://github.com/pedro-php), [@aminerol](https://github.com/aminerol), [@robertsky](https://github.com/robertsky), [@ipetrouchtchak-fi](https://github.com/ipetrouchtchak-fi), [@tinhochu](https://github.com/tinhochu), [@Lord-Kamina](https://github.com/Lord-Kamina), [@joshkel](https://github.com/joshkel), [@raiandexter0607](https://github.com/raiandexter0607), [@NateEag](https://github.com/NateEag), [@rmhaiderali](https://github.com/rmhaiderali), [@ljeda](https://github.com/ljeda)

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-03-31-v5-1-latest-release.md          )

---

# Spring Cleaning in Express.js: Deprecations and the Path Ahead

> As part of a broader effort to modernize and streamline Express.js, we’ve deprecated several outdated packages including csurf, connect-multiparty, and path-match. Learn why we made these changes and what it means for the future of the framework.

# Spring Cleaning in Express.js: Deprecations and the Path Ahead

    By

        [Express Technical Committee](https://github.com/expressjs)  16 May 2025

As Express.js continues to power web applications across the world, it’s important that we maintain a clean, reliable, and modern codebase. In that spirit, we’ve done a bit of spring cleaning.

Over the past few weeks, we’ve evaluated legacy packages within the Express.js ecosystem — some of which have become outdated, unmaintained, or misaligned with modern best practices. As a result, we’ve officially deprecated several of them.

## 🚨 Packages Deprecated

Here are the key packages we’ve deprecated:

- [csurf](https://www.npmjs.com/package/csurf): A CSRF middleware that’s long been difficult to maintain and is better handled today through frameworks or custom implementations that align with your architecture.
- [connect-multiparty](https://www.npmjs.com/package/connect-multiparty): A multipart form-data parser that relies on deprecated libraries and hasn’t aged well.
- [path-match](https://www.npmjs.com/package/path-match): A route-matching utility that has been superseded by more modern and maintained alternatives.

Each of these packages was originally created to solve real problems—but time has moved on, and the ecosystem has evolved.

## 🤔 Why This Matters

Maintaining deprecated or inactive dependencies introduces technical debt and security risk. By formally deprecating these packages, we:

- Encourage developers to adopt better-maintained and more secure solutions.
- Reduce confusion around which tools are actively supported by Express.
- Focus our efforts on modernizing the core and surrounding ecosystem.

## 🗂️ What You Should Do

If your application depends on any of these packages, now is a great time to look for alternatives. For instance:

- Consider finding a modern CSRF protection strategy on [npm](https://www.npmjs.com/search?q=csurf) that aligns with your specific needs.
- Use up-to-date multipart parsers like [multer](https://www.npmjs.com/package/multer).
- Replace path-match logic with standard [path-to-regexp](https://www.npmjs.com/package/path-to-regexp).

## 📘 What’s Next

We’re not stopping here. This cleanup is part of a broader effort to streamline Express.js, prepare for the future, and clarify what is and isn’t officially supported.

👉 A full discussion of these changes can be found [expressjs/discussions#134](https://github.com/expressjs/discussions/issues/134).

📢 Stay tuned—we’ll continue to post updates and insights as we modernize the Express ecosystem.

💚Thanks to the community for your continued trust and support.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-05-16-express-cleanup-legacy-packages.md          )

---

# May 2025 Security Releases

> Security release for Multer has been published. We recommend that all users upgrade as soon as possible.

# May 2025 Security Releases

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  19 May 2025

The Express team has released a new major version of [Multer](https://www.npmjs.com/package/multer) addressing two high-severity security vulnerabilities. This update improves the reliability and security of handling file uploads in Express applications.

Warning

We strongly recommend that you upgrade to Multer v2.0.0 or later as soon as possible.

The following vulnerabilities have been addressed:

- [High severity vulnerability CVE-2025-47935 in Multer middleware](#high-severity-vulnerability-cve-2025-47935-in-multer-middleware)
- [High severity vulnerability CVE-2025-47944 in Multer middleware](#high-severity-vulnerability-cve-2025-47944-in-multer-middleware)

## High severity vulnerability CVE-2025-47935 in Multer middleware

**Multerversions<2.0.0are vulnerable to denial of service due to a memory leak caused by improper stream handling.**

When the HTTP request stream emits an error, the internal `busboy` stream is not closed, violating Node.js stream safety guidance.

This leads to unclosed streams accumulating over time, consuming memory and file descriptors. Under sustained or repeated failure conditions, this can result in denial of service, requiring manual server restarts to recover. All users of Multer handling file uploads are potentially impacted.

**Affected versions**: `<2.0.0`
 **Patched version**: `>=2.0.0`

For more details, see [GHSA-44fp-w29j-9vj5](https://github.com/expressjs/multer/security/advisories/GHSA-44fp-w29j-9vj5).

## High severity vulnerability CVE-2025-47944 in Multer middleware

**Multerversions>=1.4.4-lts.1and<2.0.0are vulnerable to a denial of service via a malformed multipart request.**

A specially crafted request can cause an unhandled exception inside Multer, resulting in a crash of the server process.

**Affected versions**: `>=1.4.4-lts.1` and `<2.0.0`
 **Patched version**: `>=2.0.0`

For more details, see [GHSA-4pg4-qvpc-4q3h](https://github.com/expressjs/multer/security/advisories/GHSA-4pg4-qvpc-4q3h).

---

**Multer v2.0.0** also introduces a breaking change:

- The minimum supported Node.js version is now **10.16.0**.

We recommend upgrading to the latest version of Multer immediately to secure your applications.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-05-19-security-releases.md          )

---

# How Express.js Rebuilt Its Vulnerability Reporting Process

> Express.js has overhauled its vulnerability reporting workflow with a unified process, consolidated documentation, and GitHub Security Advisories enabled across all repositories.

# How Express.js Rebuilt Its Vulnerability Reporting Process

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  05 Jun 2025

The Express.js project has completed a major milestone in its ongoing commitment to security: the implementation of a formal, centralized vulnerability reporting and response process.

Until recently, security reports were typically handled over email — an approach that worked in the early days but no longer scaled with the growing complexity and user base of Express. This informal system introduced potential delays, inconsistent handling, and increased the risk of issues being missed or misunderstood.

Thanks to support from the [Sovereign Tech Fund](https://sovereign.tech), the Express.js Security Working Group has now completed a ground-up overhaul of how we manage vulnerability reports.

## 🛠️ Key Improvements

### Formalized Vulnerability Reporting Workflow

A comprehensive runbook and process flow have been created to guide maintainers through each step of triaging, confirming, and addressing reported security issues.

- [View the documentation](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md)
- [Security Report Handling Flowchart](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md#security-report-handling-flowchart)

### Unified Security Policy Across Repositories

All Express.js repositories now share a single, unified `SECURITY.md` policy to ensure consistency and remove confusion for reporters and maintainers alike.

- [View the unified Security Policy](https://github.com/expressjs/.github/blob/master/SECURITY.md)

### GitHub Security Advisories Enabled

Security Advisories are now enabled across all Express.js repositories, allowing for secure, private vulnerability reporting through GitHub’s built-in system.

- [How to report a security bug using GitHub Security Advisory](https://github.com/expressjs/.github/blob/master/SECURITY.md#reporting-security-bugs-via-github-security-advisory-preferred)

### Clear Maintainer Responsibilities

Expectations around ownership and response timelines have been clarified and published to reduce ambiguity and improve responsiveness.

> A [Security triage team member](https://github.com/expressjs/security-wg#security-triage-team) or [the repo captain](https://github.com/expressjs/discussions/blob/master/docs/contributing/captains_and_committers.md) will acknowledge your report as soon as possible.
>
>
>
> After the initial reply to your report, the security team will
> endeavor to keep you informed of the progress towards a fix and full
> announcement, and may ask for additional information or guidance.
>
>
>
> *Security Policy*

## 🛡️ Express is Now Covered Under the OpenJS Foundation CNA

As of June 2025, the [OpenJS Foundation](https://openjsf.org/) is officially a [CVE Numbering Authority (CNA)](https://openjsf.org/blog/openjs-foundation-cna), empowered to assign CVE identifiers for security vulnerabilities across its hosted projects—including Express.

What this means for the community:

- Security vulnerabilities in Express can now receive official CVE IDs through OpenJS, improving transparency and coordination.
- The foundation provides support and tooling to streamline the vulnerability disclosure process, particularly for maintainers and security researchers.
- For critical issues, the CNA helps ensure that disclosures follow best practices and are recorded in global vulnerability databases.

Please refer to [Express’s Security Policy](https://github.com/expressjs/express/security/policy) for the correct disclosure process. If needed, escalation routes through the OpenJS CNA are now available.

This advancement is part of a broader effort to strengthen the security of JavaScript’s open-source ecosystem—especially for widely used, community-driven projects like Express.

Learn more:

- [OpenJS Foundation is now a CNA – Official Blog Post](https://openjsf.org/blog/openjs-foundation-cna)
- [Socket.dev Coverage: OpenJS Foundation Becomes a CNA](https://socket.dev/blog/openjs-foundation-is-now-a-cna)

## 👀 Coming Soon: Bug Bounty Program in the Works

To further enhance the security of our ecosystem and encourage responsible vulnerability disclosure, the Express.js team has begun exploring participation in a community-focused bug bounty initiative—powered by the [Sovereign Tech Resilience program](https://www.sovereign.tech/programs/bug-resilience).

This collaboration aims to:

- Reward contributors for discovering and responsibly reporting security issues
- Improve our ability to address vulnerabilities quickly and transparently
- Strengthen long-term resilience for users and maintainers alike

Join the conversation and share your thoughts in [expressjs/discussions#345 – Bug Bounty Proposal](https://github.com/expressjs/discussions/issues/345)

## Why This Matters

Security is a shared responsibility — and one that must evolve as the project grows. With these updates, Express.js has laid the foundation for a more reliable, scalable, and transparent vulnerability response system.

We’re grateful to the [OpenJS Foundation](https://openjsf.org/) and the [Sovereign Tech Fund](https://www.sovereign.tech/) for their support and are excited to share this progress with the broader community.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-06-05-vulnerability-reporting-process-overhaul.md          )

---

# June 2025 Security Releases

> Security update for Multer released. All users are encouraged to upgrade.

# June 2025 Security Releases

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  18 Jul 2025

The Express team has released a new patch version of [Multer](https://www.npmjs.com/package/multer), addressing a high-severity vulnerability that could lead to a Denial of Service (DoS) attack.

Warning

We strongly recommend that all users upgrade to Multer v2.0.1 or later immediately.

This release addresses the following vulnerability:

### High severity vulnerability CVE-2025-48997 in Multer middleware

**Multerversions>=1.4.4-lts.1and<2.0.1are vulnerable to a Denial of Service (DoS) attack.**

An attacker can trigger this vulnerability by sending an upload request with an empty string as the field name. This malformed request causes an unhandled exception, leading to a crash of the server process.

**Affected versions**: `>=1.4.4-lts.1` and `<2.0.1`
 **Patched version**: `2.0.1`

For more details, see [GHSA-g5hg-p3ph-g8qg](https://github.com/expressjs/multer/security/advisories/GHSA-g5hg-p3ph-g8qg).

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-07-18-security-releases.md          )

---

# July 2025 Security Releases

> Security releases for Multer and On-headers has been published. We recommend that all users upgrade as soon as possible.

# July 2025 Security Releases

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  31 Jul 2025

The Express team has released a new patch version of [Multer](https://www.npmjs.com/package/multer) addressing a high-severity security vulnerability, and a new minor version of [on-headers](https://www.npmjs.com/package/on-headers) addressing a low-severity security vulnerability.

Warning

We recommend upgrading to the latest version of Multer and On-headers immediately to secure your applications.

The following vulnerabilities have been addressed:

- [High severity vulnerability CVE-2025-7338 in Multer middleware](#high-severity-vulnerability-cve-2025-7338-in-multer-middleware)
- [Low severity vulnerability CVE-2025-7339 in On-header middleware](#low-severity-vulnerability-cve-2025-7339-in-on-header-middleware)

## High severity vulnerability CVE-2025-7338 in Multer middleware

**Multerversions>=1.4.4-lts.1and<2.0.2are vulnerable to denial of service via unhandled exception from malformed request.**

This request causes an unhandled exception, leading to a crash of the process.

**Affected versions**: `>=1.4.4-lts.1, <2.0.2`
 **Patched version**: `2.0.2`

For more details, see [GHSA-fjgf-rc76-4x9p](https://github.com/expressjs/multer/security/advisories/GHSA-fjgf-rc76-4x9p).

## Low severity vulnerability CVE-2025-7339 in On-header middleware

**On-headersversions<1.1.0is vulnerable to http response header manipulation**

A bug in on-headers versions `<1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()`

**Affected versions**: `<1.1.0`
 **Patched version**: `1.1.0`

For more details, see [GHSA-76c9-3jph-rj3q](https://github.com/jshttp/on-headers/security/advisories/GHSA-76c9-3jph-rj3q).

---

We recommend upgrading to the latest version of Multer and On-headers immediately to secure your applications.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-07-31-security-releases.md          )

---

# November 2025 Security Releases

> Security release for body-parser has been published. We recommend that all users upgrade as soon as possible.

# November 2025 Security Releases

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  01 Dec 2025

The Express team has released a new patch version of [body-parser](https://www.npmjs.com/package/body-parser) addressing a moderate-severity security vulnerability.

Warning

We recommend upgrading to the latest version of body-parser to secure your applications.

The following vulnerabilities have been addressed:

- [CVE-2025-13466 in body-parser middleware (Moderate)](#cve-2025-13466-in-body-parser-middleware-moderate)

## CVE-2025-13466 in Body-parser middleware (Moderate)

**body-parserversion2.2.0is vulnerable to denial of service when url encoding is used**

body-parser 2.2.0 is vulnerable to denial of service due to inefficient handling of URL-encoded bodies with very large numbers of parameters. An attacker can send payloads containing thousands of parameters within the default 100KB request size limit, causing elevated CPU and memory usage. This can lead to service slowdown or partial outages under sustained malicious traffic.

**Affected versions**: `2.2.0`
 **Patched version**: `>= 2.2.1`

For more details, see [GHSA-wqch-xfxh-vrr4](https://github.com/expressjs/body-parser/security/advisories/GHSA-wqch-xfxh-vrr4).

---

We recommend upgrading to the latest version of body-parser to secure your applications.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2025-12-01-security-releases.md          )
