When specifying to set the return path on a store's configuration, the case (1) is to read the sender e-mail from the object instance. Now getSenderEmail derives its value from either the store configuration ("Store Email Addresses" section), or if the caller explicitly set sender data.

And, of course, notice the unescaped-append of $returnPathEmail to the -f argument. That's the root of the vulnerability.

We would typically see this happen on the use of sibling method sendTransactional, where if the $sender argument is an array, then whatever is in that array will be used to determine the return path.

So you can see that it comes down to the code serving and routing a frontend form which can be at fault. Concerning Magento core code dealing with this, I haven't done an exhaustive search, but knowing that the sender is generally set from a transactional email, I can search a code base with a simple command:

grep -A2 -rn 'sendTransactional' /path/to/magento/app/code/core/

And if the second argument could be an array, then I might have cause for concern.