Not necessarily. RCE may start with being able to run ‘something’ that has restrictions such as “can’t inject code that has zero bytes in it” or “injected code can only be X bytes long”.
In such cases, having another vulnerability available may be the easiest way to get rid of those restrictions.
Also, the second vulnerability may be complementary. For example, the first may get you onto the machine, but not out of the sandbox, while the second won’t get you on the machine, but will get you out of the sandbox.
In this case, I think the go linker won’t include the never-called vulnerable function in the executable (it only would if the vulnerability checker were smarter than the linker in detecting never-called code. That’s theoretically possible, but highly unlikely)
In such cases, having another vulnerability available may be the easiest way to get rid of those restrictions.
Also, the second vulnerability may be complementary. For example, the first may get you onto the machine, but not out of the sandbox, while the second won’t get you on the machine, but will get you out of the sandbox.
In this case, I think the go linker won’t include the never-called vulnerable function in the executable (it only would if the vulnerability checker were smarter than the linker in detecting never-called code. That’s theoretically possible, but highly unlikely)