It's possible to invoke an application without interpreting any of its arguments as shell magic:

>>> print(subprocess.check_output(["C:/testapplication.exe", "foo", "&&", "echo", "%PROGRAMFILES%"]))
Hello world from application! 5 arguments:
Argument 0: 'C:/testapplication.exe'
Argument 1: 'foo'
Argument 2: '&&'
Argument 3: 'echo'
Argument 4: '%PROGRAMFILES%'

But not so for batch scripts:

>>> print(subprocess.check_output(["C:/testscript.bat", "foo", "&&", "echo", "%PROGRAMFILES%"]))
Hello world from script! 2 arguments:
Argument 0: 'C:/testscript.bat'
Argument 1: 'foo'
C:\Program Files

I don't know if this is a fundamental limitation of Windows' batch script processing, or of the Win32 CreateProcess API, but this looks exploitable, as it allows shell injection: the subprocess docs warn about shell injection in a big red box, and promise you'll be safe if you a list of arguments and the default shell=False.

Tested on Python 2.7.15 and Python 3.6.5.

There's no simple workaround for this behavior. All we can reasonably do is document that running a batch script directly has the same security risks as using shell=True. 

CMD doesn't support a file argument. It only supports running a /c or /k command, which can include running multiple commands joined by the &, &&, or || operators. CreateProcess thus executes a .bat or .cmd script by prepending "%ComSpec% /c" to the command line. If %ComSpec% isn't defined, it defaults to "%SystemRoot%\System32\cmd.exe /c".

Environment variables in a command can be escaped in most cases by inserting the "^" escape character after the first "%" character. This disrupts matching the variable name (unless a variable name happens to start with "^"). The escape character itself gets skipped as long as it isn't quoted literally.