C++ developers worry about all UB, but we don't worry about all of them to the same extent. MITRE's CWE Top 25 [1] lists out-of-bounds write as the second most dangerous weakness, out-of-bounds read as the sixth, and use after free as number eight (null-pointer dereference and integer overflow are at nos. 21 and 23 respectively). All UBs are worrisome, but that's not to say they are equally so. Taking care of out-of-bounds is easier than UAF and at the same time more important. Priorities matter.
I don't know where that ranking comes from. It also matters that attackers adapt: UAF exploitation is harder than out of bounds, but it is well understood, and attackers can switch to it, so shutting off one source of UB isn't as effective in practice as you might expect.
It comes from MITRE (https://en.wikipedia.org/wiki/Mitre_Corporation), and the methodology is explained on the website (roughly, the score is relative prevalence times relative average vulnerability severity).
> and attackers can switch to it, so shutting off one source of UB isn't as effective in practice as you might expect.
If that's how things work, you could say the same about all the other weaknesses that have nothing to do with UB.
Interesting, for all the winging about C or C++ this shows most of these apply to all languages, and the ones that relate to C or C++ are actually pretty easy to prevent in C++(less so in C) by enabling hardening modes and using smart pointers.
Because these are ranked by prevalence x severity, and most programs are written in memory-safe languages, the UB-related weaknesses are probably at the top of the list for programs written in C or C++, especially because "ordinary" servers are usually not written in those languages. But the point is that, indeed, even within these unsafe languages, not all kinds of unsafety are equal.
It is true to say that memory-safety issues are among the biggest problems in C and C++, but it is not true to say that unless you absolutely prevent them all you remain in the same spot. If you significantly reduce or prevent some of the memory safety issues, you're in a place that's not too different from that of programs in memory-safe languages.
[1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html