This question already has an answer here:

I am trying to understand what could be the security concern of CVE-2014-6271 and all the links I see just gives me the below command.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If I get the output as,

this is a test

It means, my bash shell is vulnerable.

But in what way it is related to security? In other words, what harm could be done to my system?

marked as duplicate by jasonwryan, Anthon, Volker Siegel, Bernhard, Gilles bash Sep 25 '14 at 7:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


The security concern is that if a bash is launched with a malicious environment variable set, that bash will execute the code in the variable.

For example, lets say you have a web server that calls /bin/foo bar. Lets say this foo application also uses an environment variable called baz, and the value of this variable comes from input provided by the user. So the web server application sets the environment, and then shells out to foo bar. Well, when bash reads the environment variables, if that provided variable has malicious code, bash is going to run it.

Normally this is not a concern. Environment variables are supposed to be completely safe. If the application using that variable misbehaves, that is another matter. But bash does not use the baz variable in the situation above.

For example:


export BAZ='() { :;}; echo MALICIOUS CODE'
echo starting sleep
/bin/bash -c 'sleep 1'

When running it, we get the following

$ /bin/dash testscript.sh
starting sleep

So simply from having that variable set, we can get bash to run arbitrary code.


Here's another example that uses no explicit shell, and makes no mention of bash:

$ perl -e '$ENV{"BAZ"}="() { :;}; echo MALICIOUS CODE"; print("starting sleep\n"); system("/bin/sleep 1;");'
starting sleep

(for this to work, /bin/sh needs to be bash)

  • 1
    Thanks for the wonderful explanation. I appreciate it :) – Ramesh Sep 25 '14 at 5:22

These guys explain how you can inject code into the webserver CGI process. It basically works by setting the useragent of a request in such a way that it contains the exploit code:


'header'  => 'User-Agent: () { :;}; /bin/bash -c "'.$cmd.'"'

When that attack succeeds you can gain access to the webserver with webserver privileges and its entire content is to be regarded as compromised.


It works via sudo as well if env_reset is disabled (it's enabled by default in Debian at least)

Defaults env_reset

but if one changes it to

Defaults !env_reset (seen this on several systems in the past!!!)


sudo Y='() { disabled; }; /bin/cat /etc/shadow;' /tmp/zomg.sh

seg fault goes here

sudoers file contains :

alinh ALL=/tmp/zomg.sh

Not the answer you're looking for? Browse other questions tagged or ask your own question.