I would actually like one of our friendly IT people that frequent tFES to better explain what this is all about.
It is a *nix command processor that is frequently installed in Unix-like computers. If you are familiar with Windows, think of the "cmd" command line (although not technically a shell). It passes commands to the system and can do all kinds of powerful things, especially with scripting. The vulnerability is that there is an exploit that allows the hax0rs to use TCP protocols to execute bash commands on the local server. Basically, they can take control of a web server on the public facing Internet, or other protocols where NAT is used to expose the server to the Internet (telnet, ssh, etc.) All kinds of nasty things can be done from there assuming they have the necessary privileges.
It's a little more complex than this. Since the vulnerability is in bash (a command interpreter, or shell), an attacker would need to find a way to cause a server to execute bash. Executing a shell to process a command is very commonly done in many different server applications, so it's not infeasible, but it does require a bit of work and some luck to get a successful attack.
Additionally, the vulnerability requires setting an environment variable prior to bash being executed. An environment variable is a piece of information set by a program that can be read by another program it executes. Therefore, a successful attack relies not only on a program executing bash, but also on the attacker being able to set arbitrary environment variables. Again, this isn't particularly uncommon, but it requires some effort on the part of the attacker.
There is also the fact that this bug is easier to patch than, say, the not-too-long-ago Heartbleed vulnerability in OpenSSL. The Heartbleed bug was a library bug, and libraries will be loaded once and kept in memory by an application while running, so upgrading the library is insufficient -- you also need to restart everything that uses it. By contrast, bash is an executable that is run when it is needed, typically not loaded into memory, so just upgrading bash will secure most installations.
Finally, not all Linux distributions use bash as their system shell (although it will generally be installed on all of them). Debian, the operating system this forum runs on, uses a much more lightweight shell called dash as its system shell. Unless an application specifically asks for bash, the default command interpreter will be dash, which isn't vulnerable.
So while this would be a severe problem
if it were taken advantage of, it's difficult to predict whether an attack will be successful without knowing the details of the system you're attacking, which makes successful attacks unlikely. Combined with the fact that anyone who knows what they're doing has already patched this bug (at work, we patched all our servers the day this was announced), you have to both suck at maintaining your system and be rather unlucky to get popped. That said, it will become more likely the longer you wait to patch, as people find more and more ways to exploit it.
And yes, FES was patched long before I saw this thread. I may be too busy to post much during the week, but I'm never too busy to look after the place.
I am not entirely sure what the exploit affords them, but you would still need to elevate the privileges unless they are logged in as root which the one thing you aren't supposed to do.
The exploit allows them to essentially do anything the user they compromise is allowed to do. There are some applications which need to run as root, such as sshd, as well as OpenVPN in some configurations, and you don't get to choose which way the attacker gets in.
Best case scenario, they get in via a web server (you don't run your web server as root, right?) and start using sendmail to spam people, or mining Bitcoins. Worst case scenario, they manage to pop some root-requiring daemon and you get completely pwned.
It's all very circumstantial, but a well-managed server following general security best practices will stand a better chance against any vulnerability than one not managed properly.
Also, I am now ultra safe:
>2014
>not using Aptitude::CmdLine::Show-Versions