Is INSERT INTO SELECT vulnerable to SQL injections?

Say you let users insert their names (or anything into a table) and someone tries a SQL injection but you properly use prepared statements so the query is not affected.

$stmt = $db->prepare("INSERT INTO users (user_name) VALUES (?)");
$stmt->bindParam(1, $_POST['user_name']);

But now you use that value that was inserted in the user_name column and insert it into another table.

$stmt = $db->prepare("INSERT INTO different_table (name) VALUES (
    SELECT user_name FROM users WHERE userId = ?
)");

Does user_name get treated as a string (assuming a varchar datatype) ? In other words, do you only need to prepare the user input when it first gets inserted and comes from the client ?

Edit

If the value inside user_name contains an injection, and now I want to insert this value in another table do I need to first run a select in order to get the value and then use it in a prepared statement when I do the insert ? Like so ?

$stmt = $db->prepare("SELECT user_name FROM users WHERE user_id = 1");

Then

$stmt = $db->prepare("INSERT INTO another_table (name) VALUES (?)");
$stmt->bindParam(1, $resultFromFirstQuery['user_name']);

Or can I just do something like this ?

$stmt = $db->prepare("INSERT INTO different_table (name) SELECT user_name FROM users WHERE userId = ?");

I would claim that no SQL injection is possible because no SQL statement is getting constructed. In other words:, SQL injection can only happen in the programming language creating the SQL statement, not in the SQL statement itself.

To elaborate: the core of a SQL injection attack is that unchecked user input is used to generate a SQL statement which goes beyond the original purpose of the user input. For example, if your program does this

$sql = "SELECT * FROM Users WHERE Email = '{input.email}'"

and a user inputs

hacker@example.com' OR 1 = 1; --

for {input.email}, then the variable $sql ends up being

SELECT * FROM Users WHERE Email = 'hacker@example.com' OR 1 = 1; -- '

The security risk now comes from executing this unchecked statement on your database.

In your example no SQL is being constructed. If you execute the statement

INSERT INTO table1 SELECT * FROM table2

there is no point where unchecked user input is being appended to the query string. The result of the SELECT may contain input that would be unsafe when considered as SQL, but the values of a text field are never run as statements on the database so whether your table contains 12345 or hacker@example.com' OR 1 = 1; -- is not relevant.

The only conceivable case I could think of would be if your database server had a bug, and having some specific set of bytes in memory at a specific location could cause a memory overflow which then opens up an attack vector. But this is outside of your control and something that a database vendor would presumably fix very quickly; it is also something you can do nothing against and has nothing to do with SQL injection.