Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks.
(Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)
> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue
That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1]
The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C).
So I think looking at this with regard to what actually matters for users is completely misleading. Rust fans running around touting memory safety as the most critical thing that overrides all other considerations, but having several hundred of dependencies in statically compiled software and teaching users to do "curl | bash" is actually a disaster for security. I am not saying that memory safety is not a good thing, but this distortion of reality is harmful.
And 99% of the problem for memory safety and also any other issue goes away for the regular user if software is obtained from trusted sources that provide security support, because the window of opportunity for the attacker gets smaller. Anything that makes this harder (and this includes free software written in Rust) is a practical real-word downside for security.