Yes, this is a real thing. But just like with SQLi you can not just exploit any program, but a poorly written one with insufficient input sanitation could be vulnerable.
Lets look at interpreted languages first. For code injection to be possible here you need to have something that takes code in a string and executes it.
eval() function that does that. So if you do
eval(untrustedData) you have yourself a vulnerability. For this reason
eval() is considered "evil" and you often here the recommendation to not use it at all. There are also more sublte cases that allows execution of code from a string, like
new Function() and
In PHP you also have an
eval() function, deemed so dangerous that the manual includes a warning:
eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.
So how about compiled languages? They are less vulnerable because they don't have functions that executes arbitrary code, since that code would have to be compiled first. Off course you could write a program that generates source code (from untrusted data), compiles it, and runs it. But that would be a rather odd things to do.
You could argue, as iain does, that exploiting buffer overflows is a form of code injection, since you are injecting machine code into the program. I guess it comes down to semantics if you count that or not.