A serious security flaw was found in Bash. It could be possible to remotely execute arbitrary commands by setting an environment variable in Bash. Web servers using CGI are particularly vulnerable to an exploit, as CGI stores certain HTTP headers in environment variables, allowing an attacker to execute arbitrary bash commands by manipulating the header. You are advised to update Bash asap.

More information on technical details can be found here:

http://seclists.org/oss-sec/2014/q3/650

Please note the bug only happens with /bin/bash ... if your CGI script does the widely-recommended thing and uses the more standard /bin/sh, it's not vulnerable. Check your scripts: this is a serious flaw. Personal and game servers are a most likely target for exploits.

The exploit can be performed through mechanisms other than web server CGI scripts. For example, progarms that use the system() call (which includes Apache's mod_cgi, even if you're running Perl, Python or PhP scripts). Most widely used Linux distributions (at least Debian-derived ones) do not use /bin/bash as the default shell so again your system should not be vulnerable. I can not speak for Mac OS, but most Unixes I've used used the POSIX shell not the GNU Bourne Again Shell by default. If in doubt, check your system default shell.

Also, note that the major Linux distros have already made a patch (or 2 patches) available. You should always keep your system up-to-date with security patches.

Most routers and other embedded systems you might have are unlikely to run /bin/bash (it's a memory pig) and instead use BusyBox, so they're unlikely to be affected.

Yeah just updated my box two days ago. I'm neither using bash nor CGI anywhere though, so should be pretty safe. no?
This is all I could find in my logs so far.

209.126.230.72 - - [25/Sep/2014:07:14:13 +0200] "GET / HTTP/1.0" 404 216 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
89.207.135.125 - - [25/Sep/2014:08:27:12 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 216 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
54.251.83.67 - - [26/Sep/2014:05:39:00 +0200] "GET / HTTP/1.1" 404 197 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"

#1 Seems to be a security blog.

#2 and 3# seem to be some random vServers from the netherlands and amazon

I can not speak for Mac OS

MacOS uses bash and so is also vulnerable. Apple have yet to release a fix but people can download the bash source code and compile up their own versions with the partial fixes.

Please note the bug only happens with /bin/bash ... if your CGI script does the widely-recommended thing and uses the more standard /bin/sh, it's not vulnerable.

That depends on the underlying OS. If /bin/sh is linked to /bin/bash, you would still be vulnerable.

Pretty good big ass security flaws are been exposed lately. Sooner we learn about them, the sooner they'll get fixed.

Most widely used Linux distributions (at least Debian-derived ones) do not use /bin/bash as the default shell so again your system should not be vulnerable.

Can confirm this for Ubuntu 14.04 (/bin/sh is linked to /bin/dash).

Also something I was thinking on. The bug is extremely easy to trigger, and it has been around since 2011 from what I've read... want to bet that this bug has been widely exploited since long ago already? I seriously doubt nobody had noticed it before.

Also something I was thinking on. The bug is extremely easy to trigger, and it has been around since 2011 from what I've read

Quote from the wikipedia page:

"Analysis of the sourcecode history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 - in 1992"

That depends on the underlying OS. If /bin/sh is linked to /bin/bash, you would still be vulnerable.

No, actually. One of the other features of bash is that it checks to see what name it was invoked under and behaves differently. Since the ability to have executable code after a function definition in an environment variable was a bash feature, when invoked in POSIX mode (ie. as /bin/sh) it does not allow that and can not be exploited. Isn't that just great?

Hey kids, just say no to bash.

1992? Ouch (I had read it was a bug introduced by a patch made in 2011, but then again that was when the whole thing was just found out so maybe they were still looking into it yet?) Only makes things worse, all things considered.