This is the second time (we know of) BeamNG.drive being exploited due to bad security practices - the first time, disabling ASLR [0], leading to Disney being hacked, this time, disabling CEF sandboxing. It is weird to see them go out of their way to disable conventional security features on their product.
I'd imagine by the time your program's security is critically reliant on ASLR and process-level sandboxing, you're already in deep trouble, since any given minor update may turn existing holes into viable exploits. It will only slow down the rate of attacks at best.
The lesson I'd take here is "don't embed a web browser to run untrusted code unless you can keep it up to date 24/7". Hence the popularity of Lua interfaces for mods. Or even the alternative JS engines built for such purposes.
>It is weird to see them go out of their way to disable conventional security features on their product
Honestly with most developers I know, unless they also have a strong security background, it's not weird or surprising at all. Security features (almost?) never make debugging easier. When confronted with a failure that presents challenges devs will disable things that limit access or otherwise randomize the output in order to catch the problem and then 'hopefully' come tighten it back up when they are done. Unfortunately the second part rarely happens unless you have security auditors follow you around.
I had forced ASLR on in windows for a while... You'd be surprised how much stuff breaks with that. Almost feels like more is broken than not. Just to name a few: MinGW (including git for windows), Unity, Whatever installer Framework Signal and some others use, some Anti-Cheats
[0]: https://news.ycombinator.com/item?id=41063489