# Welcome to The Express Blog! and more

# Welcome to The Express Blog!

> Introducing the new Express blog — a primary platform for announcements, updates, and communication from the Express technical committee.

# Welcome to The Express Blog!

    By

        [Rand McKinney](https://github.com/crandmck),

        [Chris Del](https://github.com/chrisdel101)  16 Jul 2024

Welcome to the new Express blog!  The blog is meant to be a primary means of communication for the Express technical committee (TC).  While we currently have other channels such as X, LinkedIn, and of course GitHub, there’s no authoritative “soapbox” for announcements and general communication.

Initially, the Express blog will be a venue:

- For periodic announcements of new releases, pre-releases, plans, and ongoing work on the project.
- For the Express TC to discuss issues of particular importance to the Express community.
- To highlight security issues or other urgent information.

Eventually, we hope the blog will evolve into a more general communication hub for the entire Express community; for example to share examples, tips, and experiences with the Express ecosystem and other information that’s not simply technical documentation or GitHub discussion.

Initially, posts will be written by TC members (potentially collaborating others), mainly because we don’t have bandwidth to review general posts from the broader community. Eventually, we would love to open up the blog for broader contributions, but for now the focus is on trying to release Express 5.0, and the reality of an open-source project is that everyone has finite time to contribute.

Express TC member [Ulises Gascón](https://github.com/UlisesGascon) suggested a number of interesting topics for blog posts in [expressjs.com issue 1500](https://github.com/expressjs/expressjs.com/issues/1500), but there are undoubtedly many others.

If you have an idea for a post, feel free to pitch the idea! You can add a comment to [expressjs.com issue 1500](https://github.com/expressjs/expressjs.com/issues/1500) or open a new issue, and then after appropriate discussion, open a PR.  We’ve also written up simple [instructions to create a blog post](https://expressjs.com/en/blog/write-post.html).

Happy blogging!

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2024-07-16-welcome-post.md          )

---

# September 2024 Security Releases

> Security releases for Express, body-parser, send, serve-static, and path-to-regexp have been published. We recommend that all users upgrade as soon as possible.

# September 2024 Security Releases

    By

        [Ulises Gascón](https://github.com/UlisesGascon)  29 Sep 2024

Recently, the Express team has been made aware of a number of security vulnerabilities in the Express project.  We have released a number of patches to address these vulnerabilities.

Warning

We strongly recommend that you upgrade these modules to the recommended (or latest) version as soon as possible.

The following vulnerabilities have been addressed:

- [High severity vulnerability CVE-2024-45590 in body-parser middleware](#high-severity-vulnerability-cve-2024-45590-in-body-parser-middleware)
- [High severity vulnerability CVE-2024-47178 in basic-auth-connect middleware](#high-severity-vulnerability-cve-2024-47178-in-basic-auth-connect-middleware)
- [Moderate severity vulnerability CVE-2024-43796 in Express core](#moderate-severity-vulnerability-cve-2024-43796-in-express-core)
- [Moderate severity vulnerability CVE-2024-43799 in send utility module](#moderate-severity-vulnerability-cve-2024-43799-in-send-utility-module)
- [Moderate severity vulnerability CVE-2024-43800 in serve-static middleware](#moderate-severity-vulnerability-cve-2024-43800-in-serve-static-middleware)
- [Moderate severity vulnerability CVE-2024-45296 in path-to-regexp utility module](#moderate-severity-vulnerability-cve-2024-45296-in-path-to-regexp-utility-module)

## High severity vulnerability CVE-2024-45590 in body-parser middleware

**body-parserversion<1.20.3is vulnerable to denial of service when URL-encoding is enabled**

A malicious actor using a specially-crafted payload could flood the server with a large number of requests, resulting in denial of service.

**Affected versions**: `<1.20.3`

**Patched versions**: `>=1.20.3`

This vulnerability was discovered during the [OSTIF audit to Express](https://github.com/expressjs/security-wg/issues/6) and was mitigated by [the Express security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team).

For more details, see [GHSA-qwcr-r2fm-qrc7](https://github.com/expressjs/body-parser/security/advisories/GHSA-qwcr-r2fm-qrc7).

## High severity vulnerability CVE-2024-47178 in basic-auth-connect middleware

**basic-auth-connectuses a timing-unsafe equality comparison**

basic-auth-connect `<1.1.0` uses a timing-unsafe equality comparison that can leak timing information

**Affected versions**

- `<1.1.0`

**Patched versions**

- `>=1.1.0`

This vulnerability was discovered during the [OSTIF audit to Express](https://github.com/expressjs/security-wg/issues/6) and was mitigated by [the Express Securty triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team).

More details area available in [GHSA-7p89-p6hx-q4fw](https://github.com/expressjs/basic-auth-connect/security/advisories/GHSA-7p89-p6hx-q4fw)

## Moderate severity vulnerability CVE-2024-43796 in Express core

The core **expresspackage is vulnerable to cross-site scripting (XSS) attack viaresponse.redirect()**.

In Express version <4.20.0, passing untrusted user input—even after sanitizing it—to `response.redirect()` may execute untrusted code.

**Affected versions**:

- `<4.20.0`
- `>=5.0.0-alpha.1`, `<5.0.0`

**Patched versions**:

- `>=4.20.0`
- `>=5.0.0`

This vulnerability was discovered during the [OSTIF audit of Express](https://github.com/expressjs/security-wg/issues/6) and was mitigated by [the Express security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team).

For more details, see [GHSA-qw6h-vgh9-j6wx](https://github.com/expressjs/express/security/advisories/GHSA-qw6h-vgh9-j6wx).

## Moderate severity vulnerability CVE-2024-43799 in send utility module

The **sendutility module is vulnerable to template injection that can lead to vulnerability to cross-site scripting (XSS) attack**.

Passing untrusted user input—even after sanitizing it—to `SendStream.redirect()` can execute untrusted code.

**Affected versions**: `< 0.19.0`

**Patched versions**: `>=0.19.0`

This vulnerability was discovered during the [OSTIF audit of Express](https://github.com/expressjs/security-wg/issues/6) and was mitigated by [the Express security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team).

For more details, see [GHSA-m6fv-jmcg-4jfg](https://github.com/pillarjs/send/security/advisories/GHSA-m6fv-jmcg-4jfg).

## Moderate severity vulnerability CVE-2024-43800 in serve-static middleware

The **serve-staticmiddleware module is vulnerable to template injection that can lead to vulnerability to cross-site scripting (XSS) attack**.

Passing untrusted user input—even after sanitizing it—to `redirect()` can execute untrusted code.

**Affected versions**:

- `< 1.16.0`
- `>=2.0.0`, `<2.1.0`

**Patched versions**:

- `>=1.16.0`
- `>=2.1.0`

This vulnerability was discovered during the [OSTIF audit of Express](https://github.com/expressjs/security-wg/issues/6) and was mitigated by [the Express security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team).

For more details, see [GHSA-cm22-4g7w-348p](https://github.com/expressjs/serve-static/security/advisories/GHSA-cm22-4g7w-348p)

## Moderate severity vulnerability CVE-2024-45296 in path-to-regexp utility module

The **path-to-regexputility module is vulnerable to regular expression denial of service (ReDoS) attack**.

A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (`.`). For example, `/:a-:b`.

Using `/:a-:b` will produce the regular expression `/^\/([^\/]+?)-([^\/]+?)\/?$/`. This can be exploited by a path such as `/a${'-a'.repeat(8_000)}/a`. [OWASP](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) has a good example of why this occurs, but in essence, the `/a` at the end ensures this route would never match, but due to naive backtracking it will still attempt every combination of the `:a-:b` on the repeated 8,000 `-a`.

Because JavaScript is single-threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment, using Express v4 and ten concurrent connections results in an average latency of ~600ms vs 1ms.

**Affected versions**:

- `>=4.0.0`, `<8.0.0`
- `>=0.2.0`, `<1.9.0`
- `<0.1.10`
- `>=2.0.0`, `<3.3.0`
- `>=4.0.0`, `<6.3.0`

**Patched versions**:

- `>=8.0.0`
- `>=1.9.0`
- `>=0.1.10`
- `>=3.3.0`
- `>=6.3.0`

Thanks to [Blake Embrey](https://github.com/blakeembrey) who reported and created the security patch.

For more details, see [GHSA-9wv6-86v2-598j](https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j)

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2024-09-29-security-releases.md          )

---

# Express Never Ending Support Launched by HeroDevs and Express.js

> The Express.js team is pleased to announce a partnership with HeroDevs to launch Express Never-Ending Support (NES), providing long-term support for applications built with legacy Express. This collaboration ensures that developers relying on older versions of the framework will continue to receive critical security and compatibility updates, allowing them to maintain and scale their applications securely, even after the framework's official end-of-life.

# Express Never Ending Support Launched by HeroDevs and Express.js

    By

        [Express Technical Committee](https://github.com/expressjs)  01 Oct 2024

The Express.js team is pleased to announce a partnership with HeroDevs to launch [Express Never-Ending Support (NES)](https://www.herodevs.com/support/express-nes), providing long-term support for applications built with legacy Express. This collaboration ensures that developers relying on older versions of the framework will continue to receive critical security and compatibility updates, allowing them to maintain and scale their applications securely, even after the framework’s official end-of-life.

Express.js is known for its minimalistic design and flexibility, offering developers a powerful yet lightweight framework for building web and mobile applications. Its extensive set of HTTP utility methods and middleware have made creating APIs both efficient and scalable—qualities that have made it a go-to choice for Node.js developers over the years.

However, Express.js v3.x reached its end-of-life in July 2015, leaving many businesses and developers in need of support to keep their applications secure and compliant.

> “We’re grateful to see HeroDevs stepping in to provide extended long-term support for Express
>
>
>
> Express NES ensures that the many businesses and developers who rely on Express can continue using it safely and securely, even years after its original end-of-life. This kind of ongoing commitment to the open-source ecosystem is crucial, and we’re excited to see the benefits it brings to the developer community.” — said a spokesperson for the Express Technical Committee.

Express NES is designed as a drop-in replacement for legacy versions of Express.js, offering security patches, compatibility updates and compliance fixes. This solution ensures that developers can remain on legacy Express.js without becoming vulnerable to security risks and compliance issues.

> “We’re thrilled to introduce Express NES as part of our continued mission to support the sustainability of key open-source tools
>
>
>
> Our partnership with OpenJS has enabled us to meet the needs of developers still relying on older versions of critical frameworks. Express NES ensures that they can continue building and maintaining their applications without the risk of security vulnerabilities or loss of compliance.” — Joe Eames, VP of Partnership at HeroDevs.

For more information on Express NES and how to get started, visit [HeroDevs’ website](https://www.herodevs.com/support/express-nes).

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2024-10-01-HeroDevs-partnership-announcement.md          )

---

# Introducing Express v5: A New Era for the Node.js Framework

> Announcing the release of Express version 5

# Introducing Express v5: A New Era for the Node.js Framework

    By

        [Wes Todd](https://github.com/wesleytodd),

        [Express Technical Committee](https://github.com/expressjs)  15 Oct 2024

Ten years ago (July 2014) the [Express v5 release pull request](https://github.com/expressjs/express/pull/2237) was opened, and now at long last it’s been merged and published!

We want to recognize the work of all our contributors, especially [Doug Wilson](https://github.com/dougwilson), who spent the last ten years ensuring Express was the most stable project around. Without his contributions and those of many others, this release could not have happened.

Eight months ago we went public with a plan to move [Express forward](https://github.com/expressjs/discussions/issues/160). This plan included re-committing to the governance outlined years ago and adding more contributors to help kickstart progress. Many people may not realize that robust project governance is critical to the health of a large open-source project. We want to thank the [OpenJS Foundation Cross Project
Council](https://github.com/openjs-foundation/cross-project-council/) and its members for helping us put together this plan.

## So what about v5?

This release is designed to be boring!
That may sound odd, but we’ve intentionally kept it simple to unblock the ecosystem and enable more impactful changes in future releases. This is also about signaling to the Node.js ecosystem that Express is moving again.
The focus of this release is on dropping old Node.js version support, addressing security concerns, and simplifying maintenance.

Before going into the changes in this release, let’s address why it was released v5 on the `next` dist-tag. As part of reviving the project, we started a [Security working group](https://github.com/expressjs/security-wg) and [security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team) to address the growing needs around open source supply chain security. We undertook a security audit (more details to come on that) and uncovered some problems that needed to be addressed. Thus, in addition to the “normal” work done in public issues, we also did a lot of security work in private forks.
This security work required orchestration when releasing, to ensure the code and CVE reports went out together. You can find a summary of the most recent vulnerabilities patched in [our security release notes](https://expressjs.com/2024/09/29/security-releases.html).

While we weren’t able to simultaneously release v5, this blog post, the changelog, and documentation, we felt it was most important to have a secure and stable release.

As soon as possible, we’ll provide more details on our long-term support (LTS) plans, including when the release will move from `next` to `latest`. For now, if you are uncomfortable being on the bleeding edge (even if it is a rather dull edge) then you should wait to upgrade until the release is tagged `latest`. That said, we look forward to working with you to address any bugs you encounter as you upgrade.

## Breaking changes

The v5 release has the minimum possible number of breaking changes, listed here in order of impact to applications.

- [Ending support for old Node.js versions](#ending-support-for-old-nodejs-versions)
- [Changes to path matching and regular expressions](#changes-to-path-matching-and-regular-expressions)
- [Promise support](#promise-support)
- [Body parser changes](#body-parser-changes)
- [Removing deprecated method signatures](#removing-deprecated-method-signatures)

There are also a number of subtle changes: for details, see [Migrating to Express 5](https://expressjs.com/en/guide/migrating-5).

### Ending support for old Node.js versions

Goodbye Node.js 0.10, hello Node 18 and up!

This release drops support for Node.js versions before v18. This is an important change because supporting old Node.js versions has been holding back many critical performance and maintainability changes. This change also enables more stable and maintainable continuous integration (CI), adopting new language and runtime features, and dropping dependencies that are no longer required.

We recognize that this might cause difficulty for some enterprises with older or “parked” applications, and because of this we are working on a [partnership with HeroDevs](https://expressjs.com/2024/10/01/HeroDevs-partnership-announcement.html) to offer “never-ending support” that will include critical security patches even after v4 enters end-of-life (more on these plans soon). That said, we strongly suggest that you update to modern Node.js versions as soon as possible.

### Changes to path matching and regular expressions

The v5 releases updates to `[email protected]` from `[email protected]`, which incorporates many years of changes. If you were using any of the 5.0.0-beta releases, a last-minute update which greatly changed the path semantics to [remove the possibility of any ReDoS attacks](https://blakeembrey.com/posts/2024-09-web-redos/). For more detailed changes, [see thepath-to-regexpreadme](https://github.com/pillarjs/path-to-regexp?tab=readme-ov-file#express--4x).

#### No more regex

This release no longer supports “sub-expression” regular expressions, for example `/:foo(\\d+)`.
This is a commonly-used pattern, but we removed it for security reasons. Unfortunately, it’s easy to write a regular expression that has exponential time behavior when parsing input: The dreaded regular expression denial of service (ReDoS) attack. It’s very difficult to prevent this, but as a library that converts strings to regular expressions, we are on the hook for such security aspects.

*How to migrate:* The best approach to prevent ReDoS attacks is to use a robust input validation library. [There are many onnpm](https://www.npmjs.com/search?q=validate%20express) depending on your needs. TC member Wes Todd maintains [a middleware-based “code first” OpenAPI library](https://www.npmjs.com/package/@wesleytodd/openapi) for this kind of thing.

#### Splats, optional, and captures oh my

This release includes simplified patterns for common route patterns.  With the removal of regular expression semantics comes other small but impactful changes to how you write your routes.

1. `:name?` becomes `{:name}`. Usage of `{}` for optional parts of your route means you can now do things like `/base{/:optional}/:required` and what parts are actually optional is much more explicit.
2. `*` becomes `*name`.
3. New reserved characters: `(`, `)`, `[`, `]`, `?`, `+`, & `!`. These have been reserved to leave room for future improvements and to prevent mistakes when migrating where those characters mean specific things in previous versions.

#### Name everything

This release no longer supports ordered numerical parameters.

In Express v4, you could get numerical parameters using regex capture groups (for example, `/user(s?)` => `req.params[0] === 's'`). Now all parameters must be named. Along with requiring a name, Express now supports all valid JavaScript identifiers or quoted (for example, `/:"this"`).

### Promise support

This one may be a bit contentious, but we “promise” we’re moving in the right direction. We added support for returned *rejected* promises from errors raised in middleware. This *does not include* calling `next` from returned *resolved* promises. There are a lot of edge cases in old Express apps that have expectations of `Promise` behavior, and before we can run we need to walk. For most folks, this means you can now write middleware like the following:

```
app.use(async (req, res, next) => {
  req.locals.user = await getUser(req);
  next();
});
```

Notice that this example uses `async/await` and the `getUser` call may throw an error (if, for example, the user doesn’t exist, the user database is down, and so on), but we still call `next` if it is successful. We don’t need to catch the error in line anymore if we want to rely on error-handling middleware instead because the router will now catch the rejected promise and treat that as calling `next(err)`.

NOTE: Best practice is to handle errors as close to the site as possible. So while this is now handled in the router, it’s best to catch the error in the middleware and handle it without relying on separate error-handling middleware.

### Body parser changes

There are a number of `body-parser` changes:

- Add option to customize the urlencoded body depth with a default value of 32 as mitigation for [CVE-2024-45590](https://nvd.nist.gov/vuln/detail/CVE-2024-45590) ([technical details](https://github.com/expressjs/body-parser/commit/b2695c4450f06ba3b0ccf48d872a229bb41c9bce))
- Remove deprecated `bodyParser()` combination middleware
- `req.body` is no longer always initialized to `{}`
- `urlencoded` parser now defaults `extended` to false
- Added support for Brotli lossless data compression

### Removing deprecated method signatures

Express v5 removes a number of deprecated method signatures, many of which were carried over from v3. Below are the changes you need to make:

- `res.redirect('back')` and `res.location('back')`: The magic string `'back'` is no longer supported. Use `req.get('Referrer') || '/'` explicitly instead.
- `res.send(status, body)` and `res.send(body, status)` signatures: Use `res.status(status).send(body)`.
- `res.send(status)` signature: Use `res.sendStatus(status)` for simple status responses, or `res.status(status).send()` for sending a status code with an optional body.
- `res.redirect(url, status)` signature: Use `res.redirect(status, url)`.
- `res.json(status, obj)` and `res.json(obj, status)` signatures: Use `res.status(status).json(obj)`.
- `res.jsonp(status, obj)` and `res.jsonp(obj, status)` signatures: Use `res.status(status).jsonp(obj)`.
- `app.param(fn)`: This method has been deprecated. Instead, access parameters directly via `req.params`, or use `req.body` or `req.query` as needed.
- `app.del('/', () => {})` method: Use `app.delete('/', () => {})` instead.
- `req.acceptsCharset`: Use `req.acceptsCharsets` (plural).
- `req.acceptsEncoding`: Use `req.acceptsEncodings` (plural).
- `req.acceptsLanguage`: Use `req.acceptsLanguages` (plural).
- `res.sendfile` method: Use `res.sendFile` instead.

As a framework, we aim to ensure that the API is as consistent as possible. We’ve removed these deprecated signatures to make the API more predictable and easier to use. By streamlining each method to use a single, consistent signature, we simplify the developer experience and reduce confusion.

## Migration and security guidance

For developers looking to migrate from v4 to v5, there’s a [detailed migration guide](https://expressjs.com/en/guide/migrating-5) to help you navigate through the changes and ensure a smooth upgrade process.

Additionally, we’ve been working hard on a comprehensive [Threat Model](https://github.com/expressjs/security-wg/blob/main/docs/ThreatModel.md) that helps illustrate our philosophy of a “Fast, unopinionated, minimalist web framework for Node.js.” It provides critical insights into areas like user input validation and security practices that are essential for safe and secure usage of Express in your applications.

## Our work is just starting

We see the v5 release as a milestone toward an Express ecosystem that’s a stable and reliable tool for companies, governments, educators, and hobby projects. It is our commitment as the new stewards of the Express project to move the ecosystem forward with this goal in mind. If you want to support this work, which we do on a volunteer basis, please consider supporting the project and its maintainers via [our sponsorship opportunities](https://opencollective.com/express).

We have an [extensive working backlog](https://github.com/expressjs/discussions/issues/266) of tasks, PRs, and issues for Express and dependencies. Naturally, we expect developers will continue to report issues to add to this backlog and open PRs moving forward, and we’ll continue to collaborate with the community to triage and resolve them.  We look forward to continuing to improve Express and making it useful for its users across the world.

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2024-10-15-v5-release.md          )

---

# Express.js Security Audit: A Milestone Achievement

> Celebrating the successful completion of the Express.js security audit conducted by Ada Logics and facilitated by OSTIF.

# Express.js Security Audit: A Milestone Achievement

    By

        [Express Technical Committee](https://github.com/expressjs)  22 Oct 2024

We are thrilled to announce the successful completion of a comprehensive security audit for Express.js, conducted by [Ada Logics](https://adalogics.com/) and facilitated by [OSTIF](https://ostif.org/). This extensive review of our framework and its core components marks a significant milestone in our commitment to ensuring the security and reliability of Express.js for our community.

## A Collaborative Effort

This audit was made possible through the collaboration between [the Express Security Working Group](https://github.com/expressjs/security-wg), Ada Logics, OSTIF, and the [OpenJS Foundation](https://openjsf.org/). Our focus was on thoroughly evaluating the Express.js codebase, including its dependencies and core libraries. The primary goal was to identify any potential security vulnerabilities and to strengthen the overall security posture of the framework.

### Key Highlights of the Audit

- **Audit Duration**: Conducted in April and May 2024.
- **Scope**: Core Express.js codebase and critical dependencies, such as `body-parser`, `basic-auth-connect`, `serve-static`, and more.
- **Findings**: A total of 5 security vulnerabilities were identified, all of which have been addressed and patched.
- **Severity**: Issues ranged from moderate to high severity, impacting components like `res.redirect` and `serve-static`.

## A Closer Look at the Findings

The audit identified several vulnerabilities, including potential Cross-Site Scripting (XSS) risks and a Denial of Service (DoS) vulnerability in the `body-parser` middleware. Here are the key CVEs reported:

- **CVE-2024-43796**: XSS in `res.redirect`—fixed in versions >= 4.20.0 and >= 5.0.0.
- **CVE-2024-45590**: DoS in `body-parser`—patched in version >= 1.20.3.
- **CVE-2024-47178**: Timing vulnerability in `basic-auth-connect`—patched in version >= 1.1.0.
- **CVE-2024-43799**: XSS in the `send` utility module—patched in version >= 0.19.0.
- **CVE-2024-43800**: XSS in `serve-static`—fixed in versions >= 1.16.0 and >= 2.1.0.

Each of these vulnerabilities was promptly addressed by our dedicated [security triage team](https://github.com/expressjs/security-wg?tab=readme-ov-file#security-triage-team), ensuring that users remain protected against known threats.

For full details on the audit results, you can access the [official audit report here](https://ostif.org/wp-content/uploads/2024/10/expressjs-2024-security-audit-report.pdf).

## A Commitment to Transparency and Security

At Express, security is a top priority, and we believe in the importance of transparency when it comes to vulnerabilities and their resolution. This audit not only highlights our proactive approach but also reinforces our ongoing commitment to building a secure web framework for all.

We strongly recommend all users update to the latest versions of the affected packages to benefit from the recent security fixes. For more information on the patches and how to upgrade, please refer to our [September 2024 Security Release announcement](https://expressjs.com/2024/09/29/security-releases.html).

## A Word of Thanks

This audit would not have been possible without the efforts and expertise of many individuals and organizations. We want to extend our gratitude to:

- The team at Ada Logics for their diligent review and insights.
- OSTIF for their coordination and support throughout the audit process.
- The OpenJS Foundation for sponsoring this important initiative.
- Our Express.js community, who continue to support and trust us with their projects.
- [Jordan Harband](https://github.com/ljharb) for his amazing support while we needed changes in [qs](https://www.npmjs.com/package/qs).

Together, we’ve made Express.js stronger, more resilient, and ready for the challenges ahead. We look forward to continuing to serve our community with a focus on excellence and security.

Thank you for being a part of this journey with us!

 [Edit this page](https://github.com/expressjs/expressjs.com/edit/gh-pages/_posts/2024-10-22-security-audit-milestone-achievement.md          )
