-
-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintainers can delay going public #2143
Comments
I agree with this, this could also allow the possibility of retesting efforts. |
I just submitted an RCE + root escalation for a repository to Huntr.dev but decided to report it for an active fork(s) because after the fork set the vulnerability as patched it is directly published. This causes As I am was able to execute the hack on their demo server without any issue even if they patch the vulnerability on their Github packages are not rebuild and users will not update to their last version |
For example: https://huntr.dev/bounties/8c7001ce-acf3-401b-b1ad-4bc0813195d9/ As of day 14 October has been patched how ever a release hasn't been published users that uses are still vulnerable even with a POC online on how to abuse them. https://github.com/ampache/ampache hasn't been released yet (05:31 GMT) |
Thanks all for the comments. We are currently addressing the automation and publishing of CVE controls, and giving more of this capability over to the maintainer/researcher. Once we have delivered this, we may also allow for customization on the date of publishing. We will keep you up-to-date with any advancements in this. |
Maybe we could delay publications by a set amount of time by default but let the maintainer increase or decrease it? |
A default delay of 1 / 2 days make sense. It allows users to "silently" publish the packages + notify users via their own channels instead via Twitter... |
Strong agreement from me on this @JamieSlome a publishing delay is a must. We are implementing this as a process in the project right now. It is a normal part of the disclosure process to have a long enough period before publishing. In general I am missing some core principles of the responsible disclosure concept as it is practiced in Europe in the chaos computer club scene: https://youtu.be/Im45cSdmlQs |
Thank you all for your input on this! Fixing and publication are now separate states :) |
After a patch has been developed + entered in the system it would be nice to allow for a small delay for example 1 week before it get published:
Currently "Researcher" reports Vulnerability
Maintainer validates Vulnerability
Fixed will be developed and "Huntr" marks the vulnerability as fixed and publish them on the system and possible a CVE will be generated.
Incase with low impact issues for example allowing to be included It might be not an issue but for larger bugs it might be a major security issue.
For example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10966 If this would be published with 100 of servers still vulnreble and with out the possibility to give the maintainers time to publish their package and notify their users with other methods before publishing and CVE tweeting about it on the internet...
Correct method should be:
For example:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27231
It was reported in February, patched in 2 weeks later and shipped 4 month later.. As we didn't see the risks high enough and it would only a specific group of users...
The text was updated successfully, but these errors were encountered: