Also, it's still easy to detect fetch/XHR/img requests that appear out of nowhere and scrutinize them as points of interest. No matter how much your code is obfuscated and minimized, it still has to go through those APIs. There's no way around that.

Actually there is the famiar bestiary of side-channels available (eg timing, traffic modulation), along with web-specific ones (cookies, dns, non-http protocols such as webrtc, etc).

Also, fields in XHR payloads are frequently not human-readable.

Even discounting the above - scrutinizing the XHR payloads with a suspicious eye is in any event labour-intensive expert work. It happens once in a blue moon in security audits, and has a fairly low detection rate given the amount of inherently malware-like behaviour that most commercial web apps incorporate (eg img-tags used to carry tracker payloads is routine behaviour from google and facebook, and iframes used to embed terrible things).

Maybe sandbox is the wrong technical term, but JS as a language runs with constraints. It can't manipulate pointers, mainly. As far as I know there's no such thing as a buffer-overflow attack in the context of Node.js.

If the malicious JS code is already running in node, there is no need to exploit a RCE bug.

edit: to expand, an underhanded js bug might be a path traversal bug, xss bug, leak of session cookies - any of the familiar js security bugs that occur as honest mistakes too.

(But while on the subject, Node API's are historically quite unsafe and do have lots of memory safety vulns, search results are in 3 digits in the issue tracker for queries like segfault. Node API's are not really written with hostile code in mind.)