We value the community contributions to this project and believe that responsible disclosure of security vulnerabilities in open source packages helps protect the security and privacy of their users. Rather than fill this repo up with vulnerable projects, we would like to privately alert projects with details about the vulnerability and give them sufficient time to fix and provide a non-vulnerable implementation before going public. Please only update this page if you know the library or project has been fixed, and give as much detail as you can about the fix levels and date etc.
If you require help with disclosure to any projects, you can reach out to us report@snyk.io.
The TL;DR guidelines are to communicate the vulnerability privately with the affected project first and when an agreed fix has been pushed out, communicate publicly with their lists and on this repository. If you’d like us to do this for you, ask us!
Below are the full guidelines which the Snyk Security Team follow as part of our private disclosure process.
This is the first phase of the public disclosure process, with a goal to provide vulnerability details necessary for the developer to begin their internal resolution process.
If the developer has not acknowledged receipt within 30 business days of the original notification, retransmit the vulnerability details to the original contact and at least one secondary contact, if a secondary contact is publicly available. If the developer allows an additional ten business days to lapse following the second notification (40 business days since original notification) without acknowledging the information, vulnerability details will be re-sent not only to the previous two contacts, but also to other stakeholders at your discretion.
Acknowledgement of the notification by the developer should include all of the following items:
a. developer confirms the vulnerability information is received, and their schedule for investigation. b. developer provides a point of contact responsible for coordinating and tracking information on the issue from within their organization. c. developer provides an estimate as to when they expect to complete their initial investigation of the security issue provided in the notification.
Upon successful acknowledgement of the notification, work with the developer to determine how the security issue will be addressed. The following tasks are included within this phase:
a. At developer’s request, you can provide additional information to assist in the development of a solution. b. At developer’s request, you may review proposed solutions for effectiveness. c. You and the developer will exchange proposed timing for public disclosure of the issue and related solution for mutual approval.
If the developer’s responses to all communications in this phase are not received within ten business days, consider moving directly to the Public Disclosure phase.
Public Disclosure is the final phase of the disclosure process. During this phase, Your intent is to add the vulnerability to a public repository, like this one, providing information on the vulnerability and related solutions.
During the Public Disclosure phase, you, and optimally the developer, will disseminate information on the vulnerability and related solution to the public. You may disseminate information through public e-mail lists, web pages, or any other medium deemed appropriate to reach the intended audiences.