I don't think there are really any industry standards, but there are common practices that you can see from good companies and projects. I think this project i

I don't think there are really any industry standards, but there are common practices that you can see from good companies and projects. I think this project is likely one or more of these 1: fearful of what full disclosure could do, 2: ignorant to the severity of the issue, 3: feel you are over stating the risk. Any of the 3 should still be managed if they want to be taken seriously. If #1 is it, they should realize it is worse to bury it in the details as someone will point it out sooner or later. #2, well, that's just not good and they should have been asking lots of questions. #3, they should discuss it with you to try to make sure they have understood what you found fully and attempted to convince you why it isn't as severe as you think it is. The good projects/companies I see that handle these things well is put it out there and are quite blunt about it, read any security bulletin from Microsoft etc. You don't have to be so blunt you scare people away from your software, but you must be honest with the risk it poses so that people using the software feel informed enough to weigh the risk or compelled to update to the latest release etc. Or so that they know how to mitigate it through proper configuration etc. You could take an approach to put out a blog post etc how to mitigate the issue, and discuss the issue without bashing the project or its maintainers. If it is something that is used quite frequently as you say, you will be helping the community even if the project maintainers still aren't being honest enough. But I don't see it as your job to bash them, just to help the community understand the issue, know there is a patch and also that proper permission settings mitigate the risk to a certain degree.