I mean, I'm down to rip on JS/NPM any day of the week, but this specific issue isn't related to any JS/NPM-isms: it's a deserialization library which marshals language-specific objects from bytes using a variant of eval().

Any platform with eval (most implementations of Python, Perl, Lisp, Scheme, PHP, Ruby, Erlang, old editions/specific libraries of Java, Haskell, and many others) seems at risk for this type of issue.

Indeed, ser/de systems in those languages--all of them--have a long history of severe CVEs similar to this one.

It's also worth noting that this vuln has to do with the library's handling of .proto schema files, not data. The unsafe eval happens when a Protobuf schema file which itself describes the format of wire/data types is uploaded, not when the wire/data types themselves are deserialized. The majority of uses of Protobuf out there (in any language) handle the schema files rarely or as trusted input.

That doesn't make it safe/mitigated by any means, but it's worth being specific.

This is why I use Go.

I've built so much stuff in this. Code i wrote a decade back still builds and runs just fine.

It's still serving in Ad tech company, response time sub 5ms, p95

probably via normal npm injection server side.

I think something like this: Imagine a tool for querying remote grpc endpoints - you would point at some endpoint to query it / explore it, and the tool would request the proto schema files from a potentially untrusted source - something you would not expect to be that unsafe and trigger an rce.