If you really want a security story, you shouldn't be looking into a C++ server. That's a very false sense of security, there is no way to guarantee memory safety.
Absolutely not true for C++. The language was invented to guarantee memory safety, like Rust was. (The fact that people ignore the safety features when coding is irrelevant, people liberally throw 'unsafes' around in Rust and Haskell too.)
C++ wasn't invented to be safe in the same way as Rust or Ada, whose author's saw state of the art safety as a critical tenant of the language. Stroupsoup was, I believe, mostly interested in making C more suitable for large software engineering projects and was more interested in better abstractions, which could lead to better safety.
The fact that people can ignore the safety features is the point. Unsafe is a contract, and it only opens a small number of extra "features". It forms the axioms of a proof the your code correctly uses memory. C++ is essentially just patched with safer abstractions, some of which are major improvements, but there is no proof, no rigorous check for safety until runtime from asan or a fuzzer, or other tools that aren't a part of core C++.
The biggest issue with the safety of C++, however, is the size of the language. It has become so big and so complicated, and the rules that govern things we take for granted like function name lookups are horrendously unintuitive and lead to unintended consequences.
The language was invented so that Bjarne after his experience having to rewrite Simula into BCPL, never had to go through such a low level language again in his life.
Plenty of interviews where he states this, including some of his books.
leads to undefined behavior (aka the standard says the program can delete your hard drive) if x is too big, that's not a language that guarantees memory safety.
According to the spec, it can lead to all the same problems that any UB leads to, including all the problems that any memory unsafety leads to. The code is allowed by the spec to cause memory unsafety.
But to list some direct memory unsafety possibilities: indexing off the end of an array, indexing off the end of a vector, dereferencing a bad pointer, dereferencing a null pointer, dereferencing a bad iterator, double delete.
> it crashes in debug mode, and wraps (two's complement) in release mode.
Well, that's indeed a nice feature in debug mode. Mostly wraparound is undesired and wraparound bugs are pretty common. Shame the performance cost is too much to do same in release.
Whenever wraparound semantics it is actually wanted, one can use an appropriate type.
I have a big amount of love for C++, but even if the user of this framework knows about security, I would really recommend to not use it.
The risk of security issues of such framework, since it uses C++, might be quite high. I'm not into security a lot, so don't trust my word, but I'd be very cautious.
Generally, I guess higher performance means lower security.