├── docs ├── packages-in-scope.md └── threat-model.md ├── INCIDENT_RESPONSE_PLAN.md └── README.md /docs/packages-in-scope.md: -------------------------------------------------------------------------------- 1 | 2 | | Name | Github Repository | npm 3 | |---------------------|--------------------------------------------------|---------------------------------------------------| 4 | | loader-utils | https://github.com/webpack/loader-utils | https://www.npmjs.com/package/loader-utils | 5 | | analyse | https://github.com/webpack/analyse | _none_ | 6 | | watchpack | https://github.com/webpack/watchpack | https://www.npmjs.com/package/watchpack | 7 | | webpack-sources | https://github.com/webpack/webpack-sources | https://www.npmjs.com/package/webpack-sources | 8 | | tooling | https://github.com/webpack/tooling | _none_ | 9 | | schema-utils | https://github.com/webpack/schema-utils | https://www.npmjs.com/package/schema-utils | 10 | | enhanced-resolve | https://github.com/webpack/enhanced-resolve | https://www.npmjs.com/package/enhanced-resolve | 11 | | loader-runner | https://github.com/webpack/loader-runner | https://www.npmjs.com/package/loader-runner | 12 | | eslint-config-webpack | https://github.com/webpack/eslint-config-webpack | https://www.npmjs.com/package/eslint-config-webpack | 13 | | tapable | https://github.com/webpack/tapable | https://www.npmjs.com/package/tapable | 14 | | webpack-cli | https://github.com/webpack/webpack-cli | https://www.npmjs.com/package/webpack-cli | 15 | | @webpack-cli/serve | https://github.com/webpack/webpack-cli | https://www.npmjs.com/package/@webpack-cli/serve | 16 | | @webpack-cli/info | https://github.com/webpack/webpack-cli | https://www.npmjs.com/package/@webpack-cli/info | 17 | | create-new-webpack-app | https://github.com/webpack/webpack-cli | https://www.npmjs.com/package/create-new-webpack-app | 18 | | @webpack-cli/configtest | https://github.com/webpack/webpack-cli | https://www.npmjs.com/package/@webpack-cli/configtest | 19 | | webpack-dev-middleware | https://github.com/webpack/webpack-dev-middleware | https://www.npmjs.com/package/webpack-dev-middleware | 20 | | webpack.js.org | https://github.com/webpack/webpack.js.org | _none_ | 21 | | webpack-dev-server | https://github.com/webpack/webpack-dev-server | http://npmjs.com/package/webpack-dev-server | 22 | | webpack | https://github.com/webpack/webpack | https://www.npmjs.com/package/webpack | 23 | | benchmark | https://github.com/webpack/benchmark | _none_ | -------------------------------------------------------------------------------- /INCIDENT_RESPONSE_PLAN.md: -------------------------------------------------------------------------------- 1 | # Webpack Security Incident Response Plan 2 | 3 | This document defines how the Webpack project responds to security incidents. 4 | It is intended for maintainers and contributors who may need to coordinate a response. 5 | 6 | ## Scope 7 | 8 | This plan applies to incidents such as: 9 | 10 | - Vulnerabilities in Webpack core modules or official tools (e.g., `webpack-cli`, `webpack-dev-server`). 11 | - Dependency vulnerabilities that impact Webpack users. 12 | - Premature public disclosure of a vulnerability. 13 | - Account compromise or supply-chain risks affecting the project. 14 | 15 | ## Communication Channels 16 | 17 | - **Private & Preferred**: [GitHub Security Advisories](https://github.com/webpack/webpack/security/advisories). 18 | - **Email**: `webpack-security@openjsf.org`. 19 | - **Public**: GitHub releases, changelog, and advisories (after fix is available). 20 | 21 | ## Incident Response Workflow 22 | 23 | ### 1. Report Received 24 | 25 | - Reports should be submitted via GitHub Security Advisories (preferred) or private email. 26 | - **Acknowledgment timelines**: 27 | - Standard reports: within **30 days**. 28 | - Zero-day or critical vulnerabilities: within **7 days**. 29 | 30 | ### 2. Triage & Assessment 31 | 32 | - Validate whether the report is security-related. 33 | - Classify severity (critical, high, medium, low). 34 | - Determine impact and scope (affected versions, configurations, or environments). 35 | 36 | ### 3. Containment & Private Fix Development 37 | 38 | - Create a **private working group** (e.g., GitHub private fork or draft advisory). 39 | - Explore temporary mitigations if immediate patching is not feasible. 40 | - Maintain confidentiality during the process. 41 | 42 | ### 4. Fix & Testing 43 | 44 | - Develop and review a fix privately. 45 | - Add regression tests where applicable. 46 | - Backport fixes to supported major versions if relevant. 47 | 48 | ### 5. Release 49 | 50 | - Publish a patched release. 51 | - Publish a security advisory simultaneously, including: 52 | - Description of the issue. 53 | - Impacted versions. 54 | - Severity rating. 55 | - Mitigation or upgrade steps. 56 | 57 | ## Summary Table 58 | 59 | | Step | Action | Responsible Party | 60 | | --------------- | ----------------------------------------------- | --------------------------- | 61 | | Report | Submit via GH Advisory or email | Reporter | 62 | | Acknowledge | Confirm receipt (30 days / 7 days for critical) | Security Maintainer | 63 | | Triage | Validate and classify severity | Security Maintainer | 64 | | Containment/Fix | Develop patch privately | Core + Security Maintainers | 65 | | Release | Publish patch & advisory | Security Maintainer | 66 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Security Working Group 2 | 3 | ## Charter 4 | 5 | The Security Working Group manages all aspects and processes linked to the Webpack Project's security. 6 | 7 | The Security Triage Team is responsible for managing incoming security reports, to prepare security patches/releases, and to coordinate vulnerability disclosures. The nature of this task is sensitive, so only the Security Triage Team, TSC members, and (impacted) Core Maintainers are involved in the process. 8 | 9 | ### Responsibilities 10 | 11 | - Define the Security triage role 12 | - Define and maintain security policies and procedures for the project and the packages in scope (see [this table for scope details](https://github.com/webpack/security-wg/blob/main/docs/packages-in-scope.md)) 13 | - Provide guidance to the ecosystem on how to build more secure plugins 14 | - Review and recommend processes for handling of security reports. 15 | - Promote improvement of security practices within the Webpack project's ecosystem (For example: OSSF Scorecard, threat model, etc..) 16 | - Recommend security improvements for the project and the packages in scope 17 | - Support the TSC team on security triage as needed 18 | - Support initiatives from the [OpenJS Foundation Security Collab Space](https://github.com/openjs-foundation/security-collab-space). 19 | - Support initiatives from the OpenSSF [Best Practices for Open Source Developers Working Group](https://github.com/ossf/wg-best-practices-os-developers). 20 | 21 | ## Documents 22 | 23 | - [Incident Response Plan](https://github.com/webpack/webpack/blob/main/INCIDENT_RESPONSE_PLAN.md) 24 | - [Security Reporting Policy](https://github.com/webpack/webpack/blob/main/SECURITY.md) 25 | 26 | ## Current Initiatives 27 | 28 | | Initiative | Champion | Status | Links | 29 | |------------|----------|--------|-------| 30 | | Kick off the WG | [@UlisesGascon](https://github.com/UlisesGascon) | In progress | _none_ | 31 | 32 | ## Members 33 | 34 | The Security Working Group is composed of two groups of members: the Security Triage Team and the Regular members. The regular members are responsible for the public facing activity of the group, while the Security Triage Team is responsible for the security triage process. 35 | 36 | ### Security Triage Team @webpack/security-triage 37 | 38 | _TBA_ 39 | 40 | ### Lead Members @webpack/security-wg-leads 41 | 42 | _TBA_ 43 | 44 | ### Team Members @webpack/security-wg 45 | 46 | - [Aviv Keller](https://github.com/avivkeller) 47 | - [Claudio Wunder](https://github.com/ovflowd) 48 | - [Even Stensberg](https://github.com/evenstensberg) 49 | - [Rafael Gonzaga](https://github.com/RafaelGSS) 50 | - [Sebastian Beltran](https://github.com/bjohansebas) 51 | - [Ulises Gascón](https://github.com/UlisesGascon) 52 | 53 | ## Meetings 54 | 55 | The Security Working Group meets on an ad hoc basis. The meeting is open to the public. The agenda and meeting notes are published in this repository. You can find the calendar entries in the [OpenJS Foundation calendar](https://openjsf.org/collaboration). 56 | 57 | ## Offline Discussions 58 | 59 | The Security Working Group uses [GitHub issues](https://github.com/webpack/security-wg/issues) for offline discussion. The discussions are open to the public and anyone may participate. Also, the group uses the channel `#Webpack-security-wg` in the [OpenJS Foundation Slack](https://openjsf.org/collaboration) for realtime discussions. 60 | 61 | ## Code of Conduct 62 | 63 | The [Webpack Project's CoC](https://github.com/webpack/webpack/blob/main/CODE_OF_CONDUCT.md) applies to this repo. 64 | -------------------------------------------------------------------------------- /docs/threat-model.md: -------------------------------------------------------------------------------- 1 | # The Webpack Threat Model 2 | 3 | The Webpack threat model delineates what Webpack trusts at build time and what it does not trust (chiefly, inputs that can cross a network boundary when using dev tooling). 4 | 5 | For a security issue to be considered a vulnerability in Webpack (or other official tooling), it must not require compromise of trusted elements. 6 | 7 | ## Elements Webpack Does NOT Trust 8 | 9 | 1. **Network data and untrusted clients interacting with dev tooling** 10 | Any data received by [webpack-dev-server](https://webpack.js.org/configuration/dev-server/) (or equivalent dev middleware) from any source, including HTTP requests, headers, query strings, WebSocket/HMR messages, and static-file requests. This includes both malformed data and requests from clients outside the intended developer environment (e.g., due to port-forwarding, Wi-Fi sharing, or accidental exposure). 11 | *If such interactions can trigger behavior beyond what is documented (e.g., directory traversal, arbitrary file read outside configured static roots, state corruption, injection into HMR control channels, or bypassing isolation guarantees), that likely indicates a security vulnerability.* 12 | 13 | > [!NOTE] 14 | > This model is based on the assumption that **Webpack is not used as your production edge server**. If someone deploys webpack-dev-server in a production environment or makes it accessible on the public internet, the security risks that arise should be considered an operational misconfiguration, not a Webpack vulnerability. While it is still worthwhile to make development tools more resilient against misuse, that is not the primary responsibility of Webpack itself. 15 | 16 | ## Elements Webpack Trusts 17 | 18 | 1. **Developers and development infrastructure** 19 | Webpack assumes that the environment it runs in is already secured and properly configured. This responsibility covers both the infrastructure (such as local machines, CI/CD runners, container images, shell environments, operating system, and Node.js runtime) and the users who operate them, including their privileges and access rights. 20 | 21 | 2. **Build-time code and configuration** 22 | - Webpack configuration files (`webpack.config.*`) and any code they import or contain 23 | - Any CLI flags and/or other configurations 24 | - Loaders and plugins, including their transitive npm dependencies 25 | - Dev server and middleware configuration hooks 26 | - Environment variables and values injected via `DefinePlugin`, `EnvironmentPlugin`, etc. 27 | 28 | 3. **Project sources and assets** 29 | JavaScript/TypeScript, styles, templates, images, fonts, etc., within the configured project context and any paths the build intentionally resolves (`resolve.modules`, aliases, loader `include`/`exclude`, etc.). 30 | 31 | 4. **Explicitly configured network resources** 32 | Any outbound fetches/proxies that the developer *intentionally* configures in dev tooling (e.g., `devServer.proxy`) are considered trusted choices made by the developer. 33 | 34 | 35 | ## Examples of Vulnerabilities (in scope) 36 | 37 | - **Path traversal / arbitrary file read** via `webpack-dev-server` static file serving escaping configured roots. 38 | - **HMR/WebSocket message injection** that lets an unauthenticated client corrupt dev-server state, run client-side JS outside the documented HMR protocol, or crash the server. 39 | - **Reflected file serving bugs** that allow reading source maps or files outside intended scopes through crafted URLs. 40 | - **Denial of service** in dev tooling where a single unauthenticated request can lock the event loop or exhaust memory beyond documented behavior. 41 | - **Insufficient origin/host checks** in dev tooling that permit cross-origin misuse of privileged endpoints (when such checks are part of the documented guarantees). 42 | 43 | *(All of the above assume default/documented configurations and no compromise of trusted elements.)* 44 | 45 | ### Example CVE 46 | 47 | The **[CVE-2024-43788](https://www.cve.org/CVERecord?id=CVE-2024-43788)** – DOM Clobbering → XSS in Webpack Runtime 48 | 49 | In affected versions, the `AutoPublicPathRuntimeModule` relied on `document.currentScript` without verifying it was actually a `