Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
137 changes: 137 additions & 0 deletions docs/bug_bounty_details.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
# Bug Bounty Details

> [!NOTE]
> This file is a version-controlled copy of the official policy on [YesWeHack](https://yeswehack.com/business-units/sovereign-tech-fund/programs/express-js-bug-bounty-program).
It is used internally to track changes and coordinate updates.
**Do not rely on this file as the source of truth when reporting vulnerabilities. Always refer to the official YesWeHack page to ensure you have the latest and most accurate information**.

----


### Bug bounty description

| Scope Type | Scope | Asset value |
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for myself: Check that the npm versions are correctly deprecated and aligned with the LTS plan. Only express was verified

|----------|:-------------:|------:|
| Other | npm: express | high |
| Other | npm: body-parser | high |
| Other | npm: path-to-regexp | high |
| Other | npm: cookie | high |
| Other | npm: multer | high |
| Other | npm: cors | high |
| Other | npm: iconv-lite | high |

### Out-Of-Scope
- Anything related to https://expressjs.com is out of scope.
- npm packages that are not explicitly listed in the scope of the program are not accepted.


## Qualifying Vulnerabilities
To be considered in scope, a vulnerability must:

- Affect a supported, released version of one of the npm packages listed in the program scope.
- Include a reproducible proof of concept (PoC) demonstrating a real security impact.
- Arise from Express or its scoped packages incorrectly handling **network data received from inbound requests or sent via outbound responses** through documented APIs.

Examples of qualifying vulnerabilities include:

- **Incorrect parsing or serialization of HTTP data**
- Request smuggling or splitting due to malformed headers (CWE-444).
- Path traversal or header injection caused by Express’s own parsing/normalization (CWE-22, CWE-74).
- **Bypass of documented security boundaries**
- Framework-level flaws in routing or middleware execution that allow authentication/session bypass even when middleware is used as documented (CWE-285).
- Failure to enforce cookie security attributes (`Secure`, `HttpOnly`, `SameSite`) where defaults or documented APIs promise them (CWE-522, CWE-565).
- **Information disclosure**
- Leaking request bodies, session identifiers, or stack traces through Express APIs in production defaults (CWE-200).
- Sending sensitive data in unintended headers or responses (CWE-201).
- **Cryptographic/session handling flaws**
- Insecure defaults in session or cookie handling provided by Express-maintained modules (CWE-311).
- Weak randomness in session IDs or tokens generated by Express-provided utilities (CWE-330).
- **Dependency misuse**
- Express using a dependency in an insecure way that leads to a vulnerability in scope (e.g. passing untrusted data unsafely).
- **Supply chain integrity issues**
- Compromised release artifacts or publish process for in-scope npm packages (CWE-829).

## Non-Qualifying Vulnerabilities

The following are **out of scope** for this program, as they fall outside the Express threat model:

- **Denial of Service via resource exhaustion**
- Crashes, hangs, or performance degradation caused by large payloads, unbounded JSON parsing, algorithmic complexity, or slowloris-style attacks.
- Express does not guarantee protection against all forms of DoS (CWE-400).
- **Issues in trusted dependencies or runtime**
- Vulnerabilities in Node.js itself or in third-party modules used by applications.
- Bugs in libraries Express depends on, unless Express demonstrably misuses them.
- **Application misconfiguration or trusted input**
- Insecure usage of `express.static()` (e.g., exposing sensitive files).
- Prototype pollution or similar attacks requiring control of inputs provided by application code (CWE-1321).
- **Environmental or system-level manipulation**
- Modifying environment variables (e.g., `NODE_ENV`) to alter behavior.
- File system access within the permissions of the running user.
- Attacks requiring a malicious operating system, runtime, or infrastructure.
- **Reports without demonstrable real-world impact**
- Hypothetical or “theoretical” issues without a working PoC.
- Findings based solely on AI-generated scans, fuzzers, or linters without manual validation.
- **Outdated or unsupported versions**
- Issues found in versions of our npm packages that are deprecated or no longer supported.


## Policy

---

⚠️ **Your report must contain all the mandatory parts of the report submission template proposed on this program**⚠️

# Project


Express.js is a fast, unopinionated, minimalist web framework for Node.js. It provides a robust set of features for building web and mobile applications. Express handles routing, middleware, and HTTP utilities, serving as a foundational framework in the Node.js ecosystem.

The scope of this program spans multiple npm packages maintained by the Express.js team across three GitHub organizations ([expressjs](https://github.com/expressjs), [pillarjs](https://github.com/pillarjs) and [jshttp](https://github.com/jshttp)). These repositories contain the core modules, middleware components, and foundational utilities that power the Express.js ecosystem.

This bug bounty program is paid for by the [Sovereign Tech Resilience program](https://www.sovereigntechfund.de/programs/bug-resilience).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This URL redirects with 301 to https://www.sovereign.tech/programs/bug-resilience. Maybe we could use that instead


## Scopes

You can find our repositories on three different GitHub organizations ([expressjs](https://github.com/expressjs), [pillarjs](https://github.com/pillarjs) and [jshttp](https://github.com/jshttp)).

You can find the packages in npm: [express](https://www.npmjs.com/package/express), [body-parser](https://www.npmjs.com/package/body-parser), [path-to-regexp](https://www.npmjs.com/package/path-to-regexp), [cookie](https://www.npmjs.com/package/cookie), [http-errors](https://www.npmjs.com/package/http-errors), [on-finished](https://www.npmjs.com/package/on-finished) and [multer](https://www.npmjs.com/package/multer)

## Program Rules

- We welcome external reviews by security researchers in order to identify bugs in our components.
- The scope of this program only applies to the software we build, not to our CI infrastructure or our git/website hosting, and any such attack is prohibited.
- Issues must be reproducible in our setup in order to be accepted as valid.
- We operate this bounty program on a "One Fix One Reward" basis. We consider an issue duplicated if it was previously reported through other channels, and also if it affects a common code module and it was already reported for a different component.
- The Express.js project includes a variety of tools and components, many of which are independent modules, and some of which are experimental. This bug bounty program covers only a specific subset of these components, which will be explicitly defined in the scope section. The list of included components may change over time as the project evolves.
- Express.js takes an unopinionated approach to application design and security configuration. Many features are optional and intentionally flexible to accommodate a wide range of use cases. For this reason, not all security-related behaviors are enforced by default. To better understand what constitutes a valid security vulnerability within our ecosystem, please refer to the [Express Threat Model](https://github.com/expressjs/security-wg/blob/main/docs/ThreatModel.md). This document outlines what Express considers in scope for security concerns and may be updated over time as the framework and its environment evolve.

### Precautions

- Do not include Personally Identifiable Information (PII) in your report and redact or obfuscate any PII that is part of your PoC (logs, screenshot, terminal captures, etc.).

## Eligibility

Every valid report that helps us improve the security of the project is welcome, however, in order to qualify for monetary rewards the following eligibility requirements must be met at a minimum:

- The issue must originate from code published on npm, within a version of an npm package that falls under the scope of this program.
- The vulnerability must be previously undisclosed, both publicly and privately, and must not have been reported through any other channel ([security policy](https://github.com/expressjs/.github/blob/master/SECURITY.md)).
- The issue must meet the qualifying criteria defined in the program’s scope and threat model.
- The report must include a working reproducer (e.g., code, configuration, or sequence of steps) that demonstrates the issue clearly and reliably.
- You must not be a current [Express.js TC (Technical Committee) member](https://github.com/expressjs/express#tc-technical-committee), an active contributor listed in the project governance documents ([reference](https://github.com/expressjs/discussions/blob/master/docs/contributing/captains_and_committers.md)) - excluded triage and documentation (website) teams, or affiliated with any team listed in the Security WG ([ref](https://github.com/expressjs/security-wg#members)).
- Severity is assessed based on the maximum impact demonstrated by your proof of concept (PoC), not on hypothetical impact.
- Only issues affecting released npm packages are eligible. Vulnerabilities found in unreleased code, git branches, or forks are not eligible for rewards.
- **Your report must contain all the mandatory parts of the report submission template proposed on this program**



## Rating and Responsible Disclosure

CVSS is used to rate and categorize vulnerabilities. Vulnerabilities will be publicly disclosed after sufficient time has passed and fixes have been backported where needed, if deemed necessary in coordination with other maintainers.

Advisories will be published on the advisory page of our GitHub repository, and where deemed necessary as CVEs.

We handle the full disclosure process and expect submitters not to disclose any findings themselves. If requested, we will fully credit the reporters in the advisories.

The process for external reporting is described on GitHub

---
31 changes: 31 additions & 0 deletions docs/incident_response_plan.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,16 @@ Security is a top priority for the Express project. This document outlines the *

The Security Triage Team will use this document as a process guide when a security vulnerability is reported, from triage to resolution. This process must align with the project's [SECURITY policy](https://github.com/expressjs/.github/blob/master/SECURITY.md) and cannot diverge significantly.

This process applies to all security reports, whether submitted via public channels, private disclosures, or through formal bounty platforms such as YesWeHack.


## Bug Bounty Program

The Express project participates in a paid bug bounty program funded by the [Sovereign Tech Resilience Program](https://www.sovereigntechfund.de/programs/bug-resilience) and hosted on YesWeHack.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above


The goal of this program is to encourage responsible security research by providing financial rewards for qualifying vulnerability reports. Reports submitted through YesWeHack follow the same review and triage process as outlined in this Incident Response Plan.

Program Link: [https://yeswehack.com/business-units/sovereign-tech-fund/programs/express-js-bug-bounty-program](https://yeswehack.com/business-units/sovereign-tech-fund/programs/express-js-bug-bounty-program)

## Security Report Handling Flowchart
The following diagram details the **decision-making process** for handling security reports:
Expand Down Expand Up @@ -97,6 +107,7 @@ This person acts as the focal point for a specific security report and ensures t
- Oversee the advisory & CVE request process if applicable.
- Escalate critical vulnerabilities when necessary.
- Track all security reports for visibility and reporting.
- Handle communications and disputes on the YesWeHack platform (if needed)

**Requirements**
- Must be a member of the Security Triage Team.
Expand All @@ -121,6 +132,21 @@ This person acts as the focal point for a specific security report and ensures t
- Test the patch to ensure it works as expected.
- Create a pull request to merge the patch into the project.

### Bounty Liaison

This role is currently fulfilled by @wesleytodd and @UlisesGascon on behalf of the Express TC (Technical Committee).

**Responsibilities**
- Serve as the primary contact between the Express project and the YesWeHack triage team.
- Coordinate with the Sovereign Tech Resilience program team on matters related to funding, compliance, and reporting.
- Ensure bounty payouts are issued promptly and accurately for validated and accepted reports.
- Facilitate internal discussions regarding reward tiers, scope changes, and platform feedback.
- Maintain and update the YesWeHack program scope, documentation, and communication policies as needed.

**Requirements**
- Must be an active member of the Express Technical Committee (TC).


## Runbook

The following sections outline the **step-by-step process**, explaining each decision, scenario, and possible actions. In this guide we also include links that are private (limited to the security triage team), a general overview of the process in flowchart format can be found [here](#security-report-handling-flowchart).
Expand Down Expand Up @@ -186,3 +212,8 @@ Ideally, the report must contain **clear and detailed information** like (Affect
4.2 The Security Report Coordinator (SRC) will also help to publish a blog post about the vulnerability and the patch (if applicable, example [September 2024 Security Releases](https://expressjs.com/2024/09/29/security-releases.html)).

4.3 The TC team will do social media announcements about the vulnerability and the patch (if applicable, example [Tweet post](https://x.com/UseExpressJS/status/1772300472730198037)).

4.4 For reports originated in YesWeHack, the Security Report Coordinator must ensure that:
- The advisory (if public) includes an optional credit line for the reporter, based on YesWeHack preferences.
- The reward is processed per the bounty terms.
- The report is marked as resolved and paid within the YesWeHack dashboard.