Have a look at tcl's ability to run multiple iterations of itself (nested interpreters) within the same process, and how those interpreters can be sandboxed & limited to run just what you allow, & nothing more.
If you were going to handle "untrusted input", that's how you would do it in tcl.
Note: this is separate from tcl's multithreading capability, where it can also run individual interpreters per thread , with thread safe channels between them. (btw, you can mix & match both approaches - multithreading & nested interpreters)
No more so than any other dynamic language. Of course if you execute untrusted input you are asking for trouble. But Tcl has very well-defined rules for how and when substitutions and evaluations will be performed - https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm#M4 - so the programmer has full control.
One genuine problem was the you could send snippets of code to any Tcl/Tk program running on the same X server and it would execute them. Obviously X isn't the most secure of systems and you should trust your X clients, but this made it very easy if you could persuade someone to run a "command line" program. I wonder if that was fixed?
If you were going to handle "untrusted input", that's how you would do it in tcl.
Note: this is separate from tcl's multithreading capability, where it can also run individual interpreters per thread , with thread safe channels between them. (btw, you can mix & match both approaches - multithreading & nested interpreters)