Bash, aka the Bourne-Again Shell, has a newly discovered security hole. And, for many Unix or Linux Web servers, it's a major problem.
The flaw involves how Bash evaluates environment variables. With specifically crafted variables, a hacker could use this hole to execute shell commands. This, in turn, could render a server vulnerable to ever greater assaults.
By itself, this is one of those security holes where an attacker would already need to have a high level of system access to cause damage. Unfortunately, as Red Hat's security team put it, "Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue."
That could be a lot of web applications — including many of yours.
The most dangerous circumstance is if your applications call scripts with super-user — aka root — permissions. If that's the case, your attacker could get away with murder on your server.
So what can you do? First you should sanitize the web applications' inputs. If you've already done this against such common attacks as cross-site scripting (XSS) or SQL injection, you'll already have some protection.
Next, I'd disable any CGI scripts that call on the shell. (I'd also like to know why you're still using a 21-year old way of allowing users to interact with your web services. You might want to use this opportunity to replace your CGI scripts once and for all.)
After that, I'd follow Akamai's recommendation and switch "away from using Bash to another shell." But keep in mind that the alternative shell will not use exactly the same syntax and it may not have all the same features. This means if you try this fix, some of your web applications are likely to start acting up.
OpenSSH is also vulnerable via the use of AcceptEnv variables, TERM, and SSH_ORIGINAL_COMMAND. However, since to access those you already need to be in an authenticated session, you're relatively safe. That said, you'd still be safer if you blocked non-administrative users from using OpenSSH until the underlying Bash problem is patched.
It's extra work, but if I were a system administrator, I wouldn't wait for my Unix or Linux distributor to deliver a ready-made patch into my hands. I'd compile the patched Bash code myself and put it in place.
This is not a bug to fool around with. It has the potential to wreak havoc with your systems. Worse still, a smart attacker could just leave malware mines behind to steal data after the fact.
As Ellis said, "Do you have any evidence of system compromises? No. And unfortunately, this isn't 'No, we have evidence that there were no compromises;' rather, 'we don't have evidence that spans the lifetime of this vulnerability.' We doubt many people do — and this leaves system owners in the uncomfortable position of not knowing what, if any, compromises might have happened."