W3C Standards Vulnerability Disclosure & Handling Process and Policy W3C Group Note Draft 24 August 2026 More details about this document This version: https://www.w3.org/TR/2026/DNOTE-security-disclosure-20260824/ Latest published version: https://www.w3.org/TR/security-disclosure/ Latest editor's draft: https://w3c.github.io/security-disclosure/ History: https://www.w3.org/standards/history/security-disclosure/ Commit history Editors: Simone Onofri ( W3C ) Luca Lumini ( Invited Expert ) Former editor: Philippe Le Hegaret ( W3C ) Feedback: GitHub w3c/security-disclosure ( pull requests , new issue , open issues ) Repository We are on GitHub. File a bug. Commit history. Mailing list [email protected] Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract This document defines how to report suspected security vulnerabilities in W3C standards and specifications (technical reports), so that issues can be triaged, confirmed, and resolved through the appropriate W3C processes. It is not for reporting vulnerabilities in software implementations or W3C operational infrastructure (see Out of scope ). Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . Note This document is a work in progress and may be changed at any time and without notice. This document was published by the Security Interest Group as a Group Note Draft using the Note track . Group Note Drafts are not endorsed by W3C nor its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. The W3C Patent Policy does not carry any licensing requirements or commitments on this document. This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Introduction 1.1 Overview 1.2 Purpose 2. Scope and Application 3. Process and Policy 3.1 Reporting a Vulnerability in a W3C Standard 3.2 Receipt and Acknowledgment of the Security Issue (VD) 3.3 Verification of the Security Issues (VH) 3.4 Handling and Resolution Development (VH) 3.4.1 W3C Recommendations - Published 3.4.2 Candidate Recommendations (CR) and Working Drafts (WD) - In Development 3.4.3 Editor's Drafts - Early Stage/Individual Contributions 3.4.4 Discontinued, Obsolete, or Rescinded Documents 3.4.5 Community Group Reports 3.4.6 Member’s Submissions 3.5 Release and Dissemination (VD) A. Acknowledgments 1. Introduction 1.1 Overview W3C standards and specifications can contain design issues that create security risks for users, implementers, or the Web platform. Reports from researchers and the wider community help W3C identify those issues and route them to the people who can assess and address them. 1.2 Purpose This policy describes how W3C receives, triages, routes, and coordinates reports about suspected vulnerabilities in W3C standards and specifications. 2. Scope and Application W3C is a standards development organization that publishes Technical Reports, including W3C Recommendations, Notes, and Registries, which describe Web technologies and specifications. While these documents may include occasional references or example source code, W3C does not build or maintain implementations of their standards. This policy applies to design vulnerabilities or security issues described in W3C specifications . This policy does NOT cover: Implementation or configuration vulnerabilities in products, open-source projects, or services that may implement W3C standards. These issues should be reported to the corresponding vendor or maintainer. Vulnerabilities in W3C infrastructure and services that support w3.org domains. These are the responsibility of W3C Systems, which has its vulnerability disclosure policy . 3. Process and Policy W3C 's response depends on the type of technical report in which the issue was found, the severity of the issue, and the complexity of the response. W3C will work to resolve confirmed security issues without unnecessary delay. This policy is based on the recommended steps of ISO/IEC 29147 (Vulnerability Disclosure - VD) and ISO/IEC 30111 (Vulnerability Handling - VH). W3C handles and routes reports according to the type and maturity of the document in which the security issue is reported. 3.1 Reporting a Vulnerability in a W3C Standard If you think you have found a vulnerability in a W3C document, please contact [email protected] for coordinated disclosure. This email serves as the point of reference for the initial triage by the W3C Team. After triage, the W3C Team will involve the appropriate group depending on the report and the affected specification. This normally includes the Team contact, chair, and editors, and may include other people when their input is needed. It is advisable to send encrypted messages using the PGP key to [email protected] . This email does not have a public archive. Issue 1 The PGP key for [email protected] will be made available before publication. To facilitate the process, your advisory should include details such as those recommended by ISO/IEC 29147 and NIST SP 800-216: The specific document in which the vulnerability is present (e.g., its title, stable URL, and publication date). A concise description of the type of vulnerability (e.g., Use of unsafe cryptographic algorithms). Steps to reproduce the vulnerability, ideally a benign, non-destructive proof of concept. The impact of exploiting this vulnerability and how it could be used in an attack scenario. Proposed corrective or mitigating measures , if any. Your contact details (optional, to enable anonymous reporting, but helpful for follow-up clarifications). Please note that: No "Bug Bounties": W3C does not pay "bug bounties" for reported vulnerabilities. Confidentiality : The Reporter and the Coordinator involved in this policy will respect the confidentiality of information and data obtained in carrying out their tasks, especially regarding intellectual property rights, confidential business information, and public and national security interests. Sensitive vulnerability information should be communicated confidentially to minimise risk. Researcher Protections : W3C recognizes the importance of probing security research, and the potential legal challenges faced by vulnerability researchers in the course of their work. W3C will not prosecute researchers invetigating information security in good faith for that research activity. This policy is designed to be compatible with common vulnerability responsible disclosure good practice and does not permit acting in a manner inconsistent with applicable law. 3.2 Receipt and Acknowledgment of the Security Issue (VD) Once received, security issues will be acknowledged within 3 business days , establishing the communication channel with the reporter. 3.3 Verification of the Security Issues (VH) After the acknowledgement, the security issue will be evaluated to determine its validity, technical severity, relevance, and potential impact. W3C will aim to verify the issue’s validity and inform the reporter within 15 working days . If more information is needed to verify the security issue, W3C will request additional details from the source. The W3C Team is responsible for tracking these response targets and for escalating the report when more time, coordination, or authority is needed. The advisory will be handled according to the type of document to which it refers. 3.4 Handling and Resolution Development (VH) W3C will then coordinate with the reporter and the groups responsible for the affected document. In most cases, resolution will primarily involve updating the relevant document. 3.4.1 W3C Recommendations - Published These are completed, community-reviewed standards. If the Working Group that produced the Recommendation is still active, the Working Group is accountable for determining the most suitable approach to address it. If confirmed, the vulnerability might be addressed via: An erratum (for minor issues or corrections that do not change the normative content). W3C Working Groups must keep a public record of errors reported for Recommendations, compiled no less frequently than quarterly. An updated Recommendation specification document (revising the Recommendation). An entirely new document to handle the issue. If the Working Group is closed , the W3C Team is accountable for determining the most suitable approach to address the issue. The severity of the issue will determine the next steps: Minor issues can be covered with errata (potentially maintained by the W3C Team if no group is chartered). For more significant updates, the W3C Team may promote a different approach. Class 3 or 4 changes, as per W3C Process, can trigger more extensive review and patent policy implications. The issue will be handled in the Security Issue functionality on GitHub . 3.4.2 Candidate Recommendations (CR) and Working Drafts (WD) - In Development These are documents adopted by a W3C Working Group, but that they are not yet finalized. W3C Working Groups should formally address any substantive review comments about a technical report promptly. The issue will be handled on the associated Working Group mailing list or the Security Issue functionality on GitHub . 3.4.3 Editor's Drafts - Early Stage/Individual Contributions These are not officially adopted documents in W3C . Editor's Drafts, that haven't been published as a W3C specification, have no official standing. The issue should be handled and discussed with the editors of the document. Although not formally adopted, the issue can also be discussed on the associated Working Group mailing list or the Security Issue functionality on GitHub . The issue will be handled on the associated Working Group mailing list or through GitHub private vulnerability reporting for the relevant repository, where enabled . 3.4.4 Discontinued, Obsolete, or Rescinded Documents W3C Technical Reports that have been marked as discontinued, obsolete, or rescinded are unlikely to have action taken on them in response to a security issue report. Still, the Team should evaluate listing them in the Status of the document (SOTD). The issue will be handled in the Security Issue functionality on GitHub a> . 3.4.5 Community Group Reports These are not officially adopted documents in W3C , and the Community and Business Group Process regulates them . Any issues found should be handled and discussed with the editors of the document. The issue will be handled in the associated Community Group mailing list strong> or the Security Issue functionality on GitHub a> . 3.4.6 Member’s Submissions These are not officially adopted documents in W3C . Member Submissions are proposed by Members for consideration. Any issues found should be handled and discussed with the editors of the document. The issue will be handled according to the member's policy . 3.5 Release and Dissemination (VD) Once the update has been made available and sufficient time has been allowed to implement updates and releases of related technologies, W3C encourages the sharing and public disclosure of information about fixed vulnerabilities . This may include a description of the vulnerability, information that allows users to identify the affected standard, the impact and severity, and clear information to help implementers and users remediate the issue. In some cases, where security risks of publication outweigh security benefits, disclosure may be delayed until after implementers and users have had the opportunity to apply the relevant countermeasures. W3C welcomes requests to disclose your report once the vulnerability has been resolved and aims to coordinate public release. If the reporter wishes to be publicly recognized, W3C will acknowledge them for reporting the vulnerability, provided the reporter wishes to be publicly credited. A. Acknowledgments This document is based on the IETF Reporting Protocols Vulnerabilities and W3C Security Disclosures Best Practices . Several individuals contributed to the document. The editor especially thanks Philippe Le Hegaret, Ian Jacobs, and François Daoust. ↑