Bash has a feature whereby it interprets some environment variables as function definitions. For example, with the environment variable HTTP_COOKIE set to () { echo hello; }, bash parses the value of the variable as a function definition, as if the script had started with HTTP_COOKIE () { echo hello; }. The body of the function is not executed, unless the script calls HTTP_COOKIE as a command: it's the function definition that's executed.
The Shellshock vulnerability is due to interpreting the variables as more than function definitions. For example, if HTTP_COOKIE is set to () { echo hello; }; echo pwned, then bash parses and executes the function definition when it starts up, and happily goes on to execute the rest of the content of the variable, so it executes the instruction echo pwned.
With the Shellshock patch, only well-formed function definitions are accepted. A value like () { echo hello; }; echo pwned is rejected because it contains trailing code after the function definition.
The script must be written carefully and not use HTTP_COOKIE (or whatever variables have content that may be chosen by an adversary) as a command name. Only variable names that are used as command names by the script can lead to code injection: variable names that are used as variables or not used in the script are not a problem.
An environment variable defined in a CGI script has no influence whatsoever on a shell started in a terminal. Environment variables affect processes and are inherited by subprocesses, they don't somehow magically jump to other processes that happen to run the same application.
