Responses like this are why people still use C when it may make more sense to use a different language. Don’t just tell people, “trust me bro, never use C, there’s never a good reason”. Never make broad claims that leave no wiggle room, because the one thing that is always true is that there will be exceptional cases. Instead of saying this kind of stuff, why don’t you elucidate what circumstances exist where using C makes sense? Microcontrollers, FPGAs, glue code that can expose your API to other programming languages, maintaining an old code base already written in C, etc.

And as an aside, this is also why people don’t take security seriously. Not every bounds overflow will result in my database being breached and/or my computer being pwned. Instead of freaking out every time a bounds overflow or some sort of memory error is found, it may be useful to actually find out what the impact is. Is that code sandboxed? Is it local, or does it have access to the web? Does it request elevated permissions at any point? Does it even need elevated permissions?

There are many factors that can reduce or increase the risk factor of a bug. Security researchers need to start actually explaining the risk instead of blindly proclaiming everything as a “critical” vulnerability.

And everything I’m saying here has no bearing on this specific vulnerability. It’s in response to the general claim that every memory bug is critical.