At the risk of adding to the heap of "Shellshock"-related questions...
The Shellshock patch prevents arbitrary code from being executed after function definitions in environment variables. For example, here is what a patched version of Bash does when one tries to exploit the hole:
$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'
herp
This is still allowed by design:
$ env foo='() { echo derp; }' bash -c foo
derp
But if function definition through the environment is possible, then anyone with the ability to modify the environment can replace commands with arbitrary code (assuming the target script doesn't specify commands by absolute path):
$ env ls='() { echo derp; }' bash -c ls
derp
While the Shellshock patch prevents things like the HTTP User-Agent header attack, where any environment variable can be used to execute code, it does nothing to prevent redefining existing commands.
A similar attack is already possible without function inheritance by modifying PATH to point to a directory containing arbitrary maliciously-named executables, but that scenario requires filesystem access. This one does not.
The question, then: does being able to redefine commands through the environment count as a vulnerability? Is there any common situation in which it could be exploited for nefarious purposes? (For example, Git/Mercurial over SSH, Gitolite...)