Re: Oh $!#t.
In the old days, it was quite common for web servers to implement "dynamic" web pages by receiving a request over TCP, parsing the request parameters and set one environment variable for each (in the form of BLAH=FOO), and then launch some program. The program wrote its response on standard output, and that's what the web server sent back to the client. Later on it was codified as a standard as CGI-something (or similar)
The nature of the vulnerability is that if that if the program your web server is launching is bash, you have a huge problem because you can craft a request that will execute bash commands when bash is parsing its environment variables.
Of course, that's only one of the pieces of the puzzle. If the web server is properly configured the commands will not be able to alter the environment outside the context of the user that is running the web server process. But it is enough to sniff local files accessible to the web server, for example. Additional security layers may or may not mitigate the impact, but it the problem is potentially serious enough to be concerned.
Running bash scripts to process requests on a web server is 1980-era software design that is in dire need of an upgrade anyway, not only for security reasons but also because web software has evolved a lot since then. You have much better ways of doing it, either with less memory, CPU or with more functionality.
But there could still be machines out there doing this, perhaps sold as appliances that never upgrade themselves, that are vulnerable. I can only speak for myself, but certainly I haven't seen such a beast in ages.