Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string.
GET / HTTP/1.0
User-Agent: () { :; }; rm -rf /
Restricted SSH accounts (like the ones used by GitHub) have a setting to restrict the user to a specific command (e.g. /usr/local/bin/run-git-only --github-user=octocat). The original command is passed in an environment variable SSH_ORIGINAL_COMMAND. If bash is used anywhere along the way (say, if /usr/local/bin/run-git-only --github-user=octocat is a shell script), then this is a problem: ssh git@example.com '() { :; }; rm -rf /'
There are surely lots of other ways to get servers to run bash shells with arbitrary environment variables. That's why this is bad.Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....