As long as a VM doesn't execute an untrusted code, no.
Note that "executing untrusted code" includes taking code snippets from Github, StackOverflow or elsewhere and running them in a sandbox of any kind, like: a
chroot, an isolated container or a virtual machine (but except a browser sandbox, like Brython or Emscripten, once proper browser mitigations are in place).
If a VM can under any circumstances execute an untrusted code, the answer is: it depends. It's still possible that it doesn't need all or any of the mitigations a JS engine now features, but your threat model becomes much more complicated.
As of now, a few requirements must be met for your VM to be theoretically exposed to Meltdown or effects of Spectre:
The VM runs an untrusted code which can, at least, send messages to the outside world.
Including, but not limited to, Internet access or permissions to display or write data to a location which could later at some point be accessible by an attacker.
The VM allows usage of high precision timers or tools that could be used to measure relative execution time of the respective programming language instructions.
Including, but not limited to, buffers shared between concurrent threads.
The VM features optimization techniques that, at least theoretically, could allow the untrusted code to run with approximately the efficiency of compiled code.
Including, but not limited to, just-in-time (JIT) compilation or optimized bytecode generation.
It is believed, that at least in case of CVE-2017-5715, under certain circumstances (e.g. presence of particular binary instruction sequences in system libraries and a series of unfortunate events), this particular requirement could be further relaxed or lifted.
Any of the following conditions are met:
- OS mitigations for Meltdown are not applied
- The VM loads a sensitive information in the same process where the untrusted code snippet could run
- An attacker can supply some input into any other process (which has a sensitive information in its memory and runs on the same physical system the untrusted code runs on) at the same time while the untrusted code is running, from the untrusted code itself or by any other means, directly or indirectly
If all four conditions above are true, then, theoretically, your VM could be used to extract a sensitive information from your system, based on effects of Spectre and/or Meltdown.
A simple example of a virtual machine which, albeit effectively often running a third-party code, is not exposed to Spectre is the TrueType glyph hinting language VM which doesn't allow threading or instruction timing in any way, thus breaking, at least, the requirement #2.
An important note on system updates.
OS updates (e.g. KPTI for Linux) won't help to mitigate the issue completely, because:
- They target Meltdown while the main issue is Spectre;
- The only thing KPTI guarantees is that a process wouldn't be able to read kernel memory (and memory of other processes mapped into kernel space, via Meltdown only). KPTI doesn't forbid a thread in a process from reading a memory which is, from the operating system point of view, available for the whole process to read, which is the case of passwords and cookies stored in the same browser process a JS sandbox runs in.
Also, to be one hundred per cent accurate, you've asked if "similar mitigations" (to JS VM ones) are needed in VMs for other languages. Please note that a contemporary in-browser JS VM already features an overall well-designed sandbox which has limited access to filesystem, IPC, assembly language, and other system resources. In case your VM (e.g. a V8 JS VM which is shipped with Node.js platform) has more permissions or abilities than an in-browser JS VM has, it may require not similar, but further and more strict mitigations.
As of January, 14, 2018, this is in theory; but your question is also theoretical.