[{"id":3752730,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nAll reports are evaluated based on the Node.js Threat Model. You can find more information about it at [SECURITY.md](https://github.com/nodejs/node/blob/main/SECURITY.md#the-nodejs-threat-model).  All reports should be be reproducible with standard Open Source tools (, e.g. bash, python, node.js scripts) or include references to the specific source code relevant to the issue. In order to supplement the report and provide additional context is is acceptable to use other tools. Reports that can only be reproduced with non-open source tools and cannot otherwise be confirmed will be closed as \"not applicable\".\n\nNormally your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.\n\nAfter the initial reply to your report, the security team will endeavour to keep you informed of the progress being made towards a fix and full announcement and may ask for additional information or guidance surrounding the reported issue.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js\n\n\u003e-25%: A proposed patch was not provided for the issue \n\nReminder, be professional! 💼 Any report of abuse or unprofessional conduct when working with Node.js Maintainers will result in the finder being **ineligible for the IBB bounty reward.** For example, threats of bad publicity, lack of interest in pragmatic exploitability discussions, refusal to be an active participant in moving resolution forward.\n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-03-31T18:56:53.325Z"},{"id":3723930,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nAll reports are evaluated based on the Node.js Threat Model. You can find more information about it at [SECURITY.md](https://github.com/nodejs/node/blob/main/SECURITY.md#the-nodejs-threat-model).\n\nNormally your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.\n\nAfter the initial reply to your report, the security team will endeavour to keep you informed of the progress being made towards a fix and full announcement and may ask for additional information or guidance surrounding the reported issue.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js\n\n\u003e-25%: A proposed patch was not provided for the issue \n\nReminder, be professional! 💼 Any report of abuse or unprofessional conduct when working with Node.js Maintainers will result in the finder being **ineligible for the IBB bounty reward.** For example, threats of bad publicity, lack of interest in pragmatic exploitability discussions, refusal to be an active participant in moving resolution forward.\n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-21T12:17:05.748Z"},{"id":3679834,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nNormally your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js\n\n\u003e-25%: A proposed patch was not provided for the issue \n\nReminder, be professional! 💼 Any report of abuse or unprofessional conduct when working with Node.js Maintainers will result in the finder being **ineligible for the IBB bounty reward.** For example, threats of bad publicity, lack of interest in pragmatic exploitability discussions, refusal to be an active participant in moving resolution forward.\n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-11-11T13:42:42.361Z"},{"id":3662257,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 5 days, and you’ll receive a more detailed response within 10 days indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js\n\n\u003e-25%: A proposed patch was not provided for the issue \n\nReminder, be professional! 💼 Any report of abuse or unprofessional conduct when working with Node.js Maintainers will result in the finder being **ineligible for the IBB bounty reward.** For example, threats of bad publicity, lack of interest in pragmatic exploitability discussions, refusal to be an active participant in moving resolution forward.\n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-29T17:13:31.296Z"},{"id":3660065,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js\n\n\u003e-25%: A proposed patch was not provided for the issue \n\nReminder, be professional! 💼 Any report of abuse or unprofessional conduct when working with Node.js Maintainers will result in the finder being **ineligible for the IBB bounty reward.** For example, threats of bad publicity, lack of interest in pragmatic exploitability discussions, refusal to be an active participant in moving resolution forward.\n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-15T13:37:19.606Z"},{"id":3659285,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nThe Internet Bug Bounty awards security research on Node.js. If your vulnerability meets the eligibility criteria, you can submit the post-fix information to the IBB for payout. As the IBB supports the whole vulnerability lifecycle, these bounty awards are awarded as an 80/20 split, where 80% will go to you, the finder, and 20% will be given to Node.js to continue to support the vulnerability remediation efforts.\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**  \n\nTo submit eligible vulnerabilities for a payout go to https://hackerone.com/ibb for submission instructions **after the project maintainers have resolved the vulnerability.**\n\nProject Modifiers. Bounty amounts for this project are adjusted based on the following criteria:\n\n\u003e-50% : Vulnerability is not exploitable in a default configuration of Node.js \n\nThese modifiers are designed to encourage research into the most impactful areas. They are subject to change at any time by the project maintainers.\n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. The IBB team will respect their decision, and we ask that you do as well.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-05T13:56:19.879Z"},{"id":3650270,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nThird-party modules are no longer handled by the Node.js [security-group](https://github.com/nodejs/security-wg). Vulnerabilities in npm packages should be reported directly to the package maintainers. We strongly advise doing this privately. You can find contact information about package maintainers with npm owner ls \u003cpackage-name\u003e. If the source code is hosted on GitHub please refer to the repository's Security Policy. \n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nCritical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel. We often recognize any other vulnerability (e.g. Denial-of-Service attacks) with $250.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-24T04:52:15.832Z"},{"id":3639635,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated via @nodejs-ecosystem.\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nCritical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel. We often recognize any other vulnerability (e.g. Denial-of-Service attacks) with $250.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-07-15T17:45:16.672Z"},{"id":3573324,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated via @nodejs-ecosystem.\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nOnly critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in Node.js core will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-09T14:47:09.419Z"},{"id":3573283,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated via @nodejs-ecosystem.\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nOnly critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in the core Node.js programming language and standard library will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-09T03:30:23.780Z"},{"id":3573282,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated through via @nodejs-ecosystem.\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or [file an issue](https://github.com/nodejs/security-wg/issues/new).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Internet Bug Bounty Qualification\n\nOnly critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in the core Node.js programming language and standard library will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-09T03:28:37.268Z"},{"id":3573273,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated through the [Node Ecosystem Security Team](/nodejs-ecosystem).\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or email security@nodejs.org to discuss.\n\nThank you for helping keep Node.js and our users safe!\n\n## Internet Bug Bounty Qualification\n\nOnly critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in the core Node.js programming language and standard library will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-08T23:16:13.743Z"},{"id":3573272,"new_policy":"## Reporting a Bug in Node.js\n\nAll security bugs in Node.js are taken seriously. Please report any security issues [here](/nodejs/reports/new).\n\nYour report will be acknowledged within 24 hours, and you’ll receive a more detailed response within 48 hours indicating the next steps in handling your report.\n\nAfter the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.\n\n## Reporting a Bug in a third party module\n\nSecurity bugs in third party modules should be reported to their respective maintainers and should also be coordinated through the [Node Ecosystem Security Team](/nodejs-ecosystem).\n\nDetails regarding this process can be found in the [Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).\n\nThank you for improving the security of Node.js and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.\n\n## Disclosure Policy\n\nHere is the security disclosure policy for Node.js\n\n* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement.\n\n* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.\n\n* On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a copy of the advisory will be published on the Node.js blog.\n\n* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.\n\n* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.\n\n## Receiving Security Updates\n\nSecurity notifications will be distributed via the following methods.\n\n* https://groups.google.com/group/nodejs-sec\n* https://nodejs.org/en/blog\n\n## Comments on this Policy\n\nIf you have suggestions on how this process could be improved, please submit a [pull request](https://github.com/nodejs/nodejs.org) or email security@nodejs.org to discuss.\n\nThank you for helping keep Node.js and our users safe!\n\n## Internet Bug Bounty Qualification\n\nOnly critical vulnerabilities that demonstrate complete compromise of the system's integrity or confidentiality are eligible for a bounty - typically **Arbitrary Code Execution** or equivalent impact. While we encourage you to submit all potential issues, lower severity issues are not in scope at this time.\n\n| Impact  | Amount |\n| --- | --- |\n| **High** *Demonstrate that remote exploitation of this bug can be easily, actively, and reliably achieved.* | $1,500+ |\n| **Medium** *Demonstrate that remote exploitation of this bug is very likely (e.g. good control a register).* | $1,000 |\n| **Minimum** *Demonstrate the presence of a security bug with probable remote exploitation potential.* | $500 |\n\nOnly vulnerabilities in the core Node.js programming language and standard library will be considered for eligibility. **Submissions related to *nodejs.org* and other project websites are explicitly NOT eligible.**   \n\nThe project maintainers have final decision on which issues constitute security vulnerabilities. [The Panel](https://internetbugbounty.org/#the-panel) will respect their decision, and we ask that you do as well.\n\nIt's important to keep in mind that not all submissions will qualify for a bounty, and that the decision to award a bounty is entirely at the discretion of the Panel.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-08T23:15:06.822Z"}]