Prototype poisoning (2019)

Sorry, it took me awhile to respond because I struggled to articulate this in a way that didn’t simply appeal to “this is the way literally everyone does it for obvious reasons” appeal-to-crowds (though it is, in fact, near-universal practice). The reasons I’m familiar with are below; there are likely others I’m not listing:

Because bad actors should be presumed to already be exploiting the vulnerability, so anything less than prudently fast and loud disclosure to as many of your users (direct or transitive) as possible increases the likely damage caused by the vulnerability.

Because, as you say, urgent needed-for-security updates are likely to motivate more people to update quickly. In addition to the scare factor, consider that many people want to update dependencies but can’t get the work prioritized. For those folks, a scary security bulletin may be what they need to get the ticket moved to the front of the queue.

Because release diffs, even “sneaky” semver-trivial ones, of popular libraries are some of the most scrutinized code by bad actors, both because new releases often contain vulnerabilities that can be exploited before anyone else knows about them, and because bad actors know about the sneaky-release trick so they know to look for code like this, even if you try to obfuscate it.

Because the potential downside of getting caught sneaking a fix into a trivial release when you knew that there was a significant vulnerability out there is much worse than the downside of telling all your users that your software was insecure before so-and-so version. If folks savvy to what you did after the fact and you respond with “well you should have been keeping your transitives updated anyway”, that will buy you precisely zero goodwill with people who have suffered a data breach. The best you can do is document loudly and publicly that you responded to the vulnerability as well as possible as soon as you learned about it, so that nobody can accuse you of dragging your feet or of sweeping it under the rug. Yeah, you’re gonna lose some users when you notify folks about a vuln, but you’re likely to lose more users if you end up known as someone who conceals vulnerabilities.

Because a lot of code that may be using your library in a vulnerable way is closed-source, so statements like "hapi was the only major attack vector” are not something you can accurately make. Sure, maybe that’s a reason why more folks should participate in Free Software. But those companies and their customers that just got hacked don’t care about that distinction, they care that you could have been louder about the issue--loud enough that automated CVE-found-in-library-you-use scanners they run against their proprietary codebases set off alarm bells--and were not.

Again, because you should assume that bad actors are already exploiting the issue by the time you discover it. It’s tempting to assume that subtle vulnerabilities aren’t being exploited because they’re subtle; that’s usually false--bad actors have time and regrettably impressive expertise in this area. It’s also tempting to assume that if exploits in the wild aren’t making headlines/getting reported to you, they aren’t happening; that’s usually false--many companies don’t know they’re being hacked until long after it happens, or ever. Even if users do know they were compromised, often don’t know what the vector was, so they can't attribute it to your software. Even if they do know the vector was your software, they often don’t reach out to the maintainers (seriously, the amount of monkey-patch/internal-and-dubiously-legal-fork code I’ve seen that remediates very significant security issues in popular libraries is large. Some of those libraries had corporate owners and impossible-to-miss instructions for security issue reporting, but the users chose to monkey patch instead). Sometimes they want to reach out but can't, for fear of internal reprisal, or due to language barriers, or some other reason.