How to Manually Update Bash to Patch Shellshock Bug on Older Fedora-Based Linux Systems 176

Shellshock Bash BugWith the announcement of the Shellshock Bash Bug, Linux admins around the world have been scrambling to patch their Bash shells so that they’re no longer vulnerable to the exploit. If you have a Fedora, RHEL, or CentOS system that hasn’t reached End-Of-Life, then updating to a patched version of Bash is as simple as:

sudo yum update -y bash

But what if you have a system running Fedora 12, Fedora 13, Fedora 14, Fedora 15, Fedora 16, Fedora 17, Fedora 18, or Fedora 19… or even RHEL/CentOS 3 or RHEL/CentOS 4, or an older SUSE Linux box?  I have a Fedora 12 box I keep around for testing, and an updated version of Bash isn’t available in the repos. In that case, you can actually download the Bash source, manually apply all the patches, and compile and install it manually. It’s not as hard as you think! In fact, check out the comments for reports of people successfully patching all the way back to Fedora 4 using this method!

Ubuntu users: There’s actually no reason this approach won’t work with any Linux-based OS, including Ubuntu. You just need to use your system’s package manager (which is apt if you’re using Ubuntu) to install any required packages you’re missing in Step 3. But if you don’t need to install any additional packages, then these instructions will work just fine on Ubuntu, too.

Before You Start

It’s likely you’ve already done this step before coming here, but here’s how to check to see if you’re vulnerable to the Shellshock Bug. Check your vulnerability by running the following tests from your shell:

Exploit 1 (CVE-2014-6271)

Running the following command in a shell.

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

If you see “vulnerable” you need to update bash. Otherwise, you should be good to go.

Exploit 2 (CVE-2014-7169)

Even after upgrading bash you may still be vulnerable to this exploit. Try running the following code.

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

If the above command outputs the current date (it may also show errors), you are still vulnerable. If it just spits out the word “date,” then you’re fine against this exploit. It’s possible after running this test that you’ll have new file named  “echo” in your /tmp directory. If that’s the case, it’s fine to delete it. IMPORTANT: Some of the tests floating around out there for this exploit (including the one I used to reference) include the command “rm -f echo” and could potentially delete the /bin/echo file on your system… which (ironically) is required when building a patched version of Bash. Don’t attempt any tests that include “rm -f echo.” If you did accidentally remove your /bin/echo file, you can restore it by searching for an archive of the core-utils RPM package for your particular system, then use “rpm -iv –replacepkgs” when installing it to force it to re-install and restore the deleted /bin/echo file.

Exploit 3 (???)

Here is another variation of the exploit.

env -i X=' () { }; echo hello' bash -c 'date'

If the above command outputs “hello”, you are vulnerable.

Exploit 4 (CVE-2014-7186)

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

If you see “CVE-2014-7186 vulnerable, redir_stack” as part of the output, you are vulnerable to this exploit.

Exploit 5 (CVE-2014-7187)

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

If you see “CVE-2014-7187 vulnerable, word_lineno” as part of the output, you are vulnerable to this exploit. IMPORTANT: Keep in mind that as new Bash exploits are being discovered, new patches are being released by the Bash developers. For example, this article was first published on Sep 26, 2014, and additional patches were released within 2 days (which are now included in the instructions below). Still another patch was released on October 1, 2014. I will continue to update this post as new patches are available. Keep in mind that if the current patches don’t fix all the above known vulnerabilities on your system, you are still better off patching to the highest level possible, and then re-patching later (by simply following these instructions again) when new patches are released.

Step 1: Back up your existing Bash binary

Find out where your existing bash binary is located on your system with:

which bash

You’ll get a response like:


Backup that file with:

sudo cp /bin/bash /bin/bash.old

Step 2: Determine which version of Bash you’re running

Now you’ll need to determining which version of bash your system is running. If you’re running Fedora 12, for example, it’s probably version 4.0. You can find out your version with:

bash --version

which will spit out a version number that looks something like this:

GNU bash, version 4.0.1(1)-release (i686-redhat-linux-gnu)

The first two numbers in 4.0.1 means you’re running Bash version 4.0. Remember your version number, as you’ll need that later. The third number in 4.0.1 can be a bit confusing, because it will mean something different based on where it came from. In this example, because “redhat” appears in the description, the third number is the build number in the RedHat repositories. However, if your output looked like this:

GNU bash, version 4.0.45(1)-release (i686-pc-linux-gnu)

the fact that it says only “pc” in that part of the description means Bash was manually compiled on your system (probably by you) and so in that case, the third number refers to the patch level of Bash version 4.0. Your goal at the end of this post is to have Bash report a version that looks like this, with the highest possible patch level. Do not confuse the Bash version with the patch level! Your goal during this fix should be to keep your version number the same, but increase your patch level to the highest possible number. A higher version number doesn’t necessarily mean you’re protected. Being patched to the highest patch level, regardless of your version number, is what you care about in this case. Finally, as you move through the following steps, resist the urge to move to a newer version number of Bash versions… as you’ll probably end up causing more problems than you’ll fix. Patching your current version of Bash is the best option to ensure things keep working on your system.

Step 3: Set up your fix environment

Whenever I’m working with source code on a Linux box, I like to keep everything in the /usr/local/src directory. So create a new subdirectory for fixing bash, and then jump into that directory, with:

mkdir /usr/local/src/bashfix
cd /usr/local/src/bashfix

You should also make sure you have a few required packages that will come in handy later (like patch, byacc, bison, autoconf, etc.) do:

sudo yum install patch byacc textinfo bison autoconf gettext ncurses-devel

Step 4: Download the Bash source

Locate the matching source code for the version of Bash you’re already running on the FTP server. Since my test system was using 4.0, that’s what I’ll download in this example, but you should obviously download the one that’s appropriate for your system. Again, resist the urge to upgrade to a newer version (such as 4.1, 4.2, or 4.3 in this example). This can potentially create serious problems. Just stick with what you’ve already got for now. Download and extract the appropriate Bash source code into your fix directory with:

tar zxvf bash-4.0.tar.gz

You should now have a new sub-directory containing the bash source. In this example, that directory is /usr/local/src/bashfix/bash-4.0. Move yourself into the newly extracted bash source code directory with:

cd bash-4.0

Step 5: Download and Apply the Patches

If you check the FTP server where you downloaded the source code, you’ll also see a few sub-directories for each major version that contain all the patches for that version. Different versions of Bash have a different number of patches. In our example, the patches are located in Checking that directory (as of  Oct 5, 2014) shows a total of 44 patches for version 4.0, from  bash40-001 to bash40-044. Your first option is to download the first patch, apply it to the source code, then download the second patch, apply it to the source code, and so on. Don’t do this just yet, because I’m going to show you a faster way to do it. But you should at least understand what’s happening before you automate it. The command you’d use to download the first patch and apply it in a single step would be (again, don’t do this… it’s just for illustration):

curl | patch -p0

That command uses curl to download the patch 001, then pipes the downloaded patch into the patch command, which patches the source code in that directory (you can check the patch man page for more details, if you want). If you did this manually, you’d have to repeat this command for each individual patch file, changing the 001 to 002, and then again changing it to 003, and so on until you reached the final patch. But my buddy Steve Cook helped me write a script (I stored it on GitHub as a Gist) that will automate all the patching for you. You just need to tell it the bash version you’re patching, and the total number of patches available for that version. Check it out:

Make sure you’re in the Bash source code directory you extracted, then download the “raw” version of the script we wrote with:


Edit the file with your favorite text editor and set the version, nodotversion, and lastpatch variables in the script to the appropriate values for your situation (the nodotversion is simply the version number of bash without a dot in the middle). In our example, the variables are 4.0 (because we’re using Bash 4.0), 40 (same as the version without the dot), and 44 (since there are 44 total patches available for this version of Bash). Depending on your version, the number of patches will be different.

I do my best to stay on top of this issue, but It’s possible that even more patches are available in the patches directory before I’ve had a chance to update this article. You should always set the lastpatch variable in the script to the last patch you see in the directory to ensure the highest level of vulnerability protection. Save your edited file, then make it executable with:

chmod 755

Now run it inside the Bash source code directory with:


Depending on your connection speed, it shouldn’t take very long to download all the patches and apply them. You’ll see each download and patch happen on your screen as the script runs. Keep an eye out for any error messages. The very last one should look something like this:
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
102 3882 102 3882 0 0 10438 0 --:--:-- --:--:-- --:--:-- 53178
patching file builtins/evalstring.c
patching file parse.y
patching file shell.h
patching file patchlevel.h

You can verify your source is patched to the level you want with:

cat patchlevel.h

If you look near the end of that file and see #define PATCHLEVEL followed by the last patch available for your version, then your source is patched to the highest level and should address the Shellshock Bug. Now you’re ready to build the patched version of your bash binary.

Step 6: Build and Install your Patched Bash Binary

It’s best if the “configure” and “make” steps in this section are performed as a regular, non-root user. However, on particularly older systems, if you’re getting errors other than missing dependencies when running “configure,” you may just have to do them as root.

In the source code directory, do:


You’ll see your system check to make sure everything is ready for your build. If you don’t see any errors, go ahead and make the new binary with:


Then test with:

make test

When everything is done you should be able to do this command:

ls -la bash

And you’ll see a newly build Bash binary with a timestamp of just a few seconds ago, like this:

-rwxrwxr-x 1 root root 2273014 2014-09-28 08:37 bash

Now copy the new binary to where your old bash binary was located in Step 1 (which is almost certainly /bin/bash) with:

sudo cp -f bash /bin/bash

Step 7: Test Your Fix

Now that you’ve manually downloaded, patched, compiled, and installed a new bash, you should test it to make sure you’re no longer vulnerable. Make sure your current shell session is using your newly compiled bash by simply running the new location from the command line. In this example, that would be:


First, check to make sure you’re running the newly compiled version with:

bash --version

The output should look like:

GNU bash, version 4.0.44(1)-release (i686-pc-linux-gnu)

The 4.0.44 means you’re running Bash 4.0 at patch level 44. If that was the highest patch you applied to your source, then you are running the version you just built. Now run the vulnerability tests at the top of the article again. As I stated earlier, it’s possible that patches aren’t available to address all of them yet, but you should still patch to the highest level available, and then check back frequently to see if newer patches are available. Also, make sure you log out of any current shell sessions, and log in again using your new shell.

UPDATE! Step 8: Check For (and Kill) Any Old Bash Binaries in Memory

My buddy and fellow Linux sysadmin Todd Lyons emailed me a few days after I wrote this post, and informed me that (particularly on Fedora-based systems) he’d discovered that the old vulnerable Bash binary might still be in memory — even after building and installing a patched version. When I tested his theory on my system, I found he was absolutely right.  So once you’re finished with this patch, read my post on how to prevent your vulnerable Bash binary from being “resurrected.”

If this article was helpful to you, I’d appreciate you sharing or tweeting it! 🙂

Congratulations on a successful fix! As always, I welcome your questions, comments, and feedback below!

UPDATE #2: Fully Automated Bash Update Script

A generous reader of my blog named Mike Marino was kind enough to write a script based on the steps in this article to cleverly automate the manual Bash update process (including the patching functions of the script). I’ve created a Gist of the script he emailed to me, and named it It essentially follows all the steps in this post, including figuring out your current version of Bash and which patches you need. Mike reports that he’s “been using it to resolve Shellshock on hundreds of hosts which  are stuck running officially unsupported versions of OSes.” It works great! I still recommend that you understand all the steps it’s doing before you pull the trigger, but if you’ve read this far, I’m assuming you already do.

When I replied to Mike to thank him, and ask if I could link to his blog or Twitter feed, his response was “I do not have a blog or anything. Thanks for the offer though. Just my way of giving back on all that you gave us. You can just mention a reader submitted it based off all your awesomeness.”

So thanks, Mike! Your script is awesomeness. 🙂

Further Reading:

Thank you to the authors of these blog posts, which were helpful in patching Bash on my “outdated” Fedora 12 test box, as well as in writing this post.

  • mdk999

    Thanks for this.. two small notes
    1. add cd into the bash directory
    2. make a note that you’d need to install patch (yum install patch -y). I was working on system and it was not installed.

    • Hi, MDK. Thanks. I’ve edited to add the patch install, and while the “cd into the bash” directory step was already included in Step 4, I’ve reworded it to make it a bit more obvious. Thanks!

  • What can I say… THANK YOU… You saved me a lot of time in rediscovering the wheel and getting the patched version and compiling it. I will eventually move my site to the new Centos 6.5, but recompiling bash was the interim quick fix. One comment… I had to use the -f option on the
    cp -f /usr/local/bin/bash /bin/bash
    since my bash was obviously “in use”.

    • Thanks, Jan. I’ve edited to include the -f. Great suggestion.

  • This fixes Centos 4.6 running 3.0 bash, you do have to make sure and copy over the the /bin/bash with the new bash 3.0.18 or the sh will still be vulnerable as stated above. If you run into problems moving the file because it is in use simply rename it something else I used bashold and then copy the new bash over, works like a charm. Now I can put off upgrading awhile longer…

    mv /bin/bash /bin/bashold
    cp /local/usr/bin/bash /bin/bash

  • AJ

    Got an error on the make. Using Fedora 17 and bash 4.2
    yacc -d ./parse.y
    make: yacc: Command not found
    make: *** [] Error 127

    • AJ — try

      yum install byacc

      That worked for me.

  • Hi,

    Nice work. Some notes:
    0. after running
    $ make, one should run
    $ make test

    NOTE: the compilation and make test should run as a regular, none root user.
    You only need super user privs for copying the new binary to /bin/bash

    1. no point in running make install if you plan to copy to /bin/bash, you can just
    cp -f bash /bin/bash
    running make install, unless you provided an alt prefix with –prefix, will install under /usr/local/bin which just means you’ll have 2 versions of the same in different places, it is just confusing if you ask me.


    • Thanks, Jess. Great suggestions, and I’ve updated the post.

  • Thank you SO MUCH. This worked on my FC12 *and* my FC9 servers. Your instructions were perfect. Thank you again.

  • Thomas Leow

    The procedure worked for Fedora 14.


  • [[email protected] ~]$ uptime
    10:32:48 up 1483 days, 21:01, 4 users, load average: 0.00, 0.00, 0.00


  • Thomas Leow

    The procedure did not work for Fedora 17.

    bash-4.2]$ ./bash
    bash: command substitution: line 1958: syntax error near unexpected token `)’

    • Hi, Thomas. That sounds like maybe one of the patches didn’t apply properly. What happens if you start from scratch and apply the patches manually, checking the output of each one individually?

      • Thomas Leow

        I repeated the same procedure for Fedora 20. Same errors happened. Both systems had bash-completion.

        Your details had helped me patched the older versions, such as Fedora 14. Thanks.

  • J.F. Hardy

    Thank you! Worked great, although I also got the yacc error, per a previous user’s comments. Installing bison fixed it (from, pick the version that would match your bash’s version, then ./configure, make, make install).

    • Thx, JF. I went ahead and added bison to the list of suggested packages to have installed. Yum was still able to install it on my FC12 test box.

  • Richard

    Great instructions – thank you, but for some reason the new bash shell still has the exploit (says “busted”). It’s an “” virtual host. I’m definitely hitting the new shell as it used to report RedHat and now reports GNU from “bash –version”:

    GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
    Copyright (C) 2007 Free Software Foundation, Inc.

    • Richard

      School boy error – heeding the warning about changing version I only patched to the same patch level, not the highest patch level (which of course contains the fix). Re-ran with the highest patch level (53 in this case!) and all works as expected.

      Thanks again.

  • Mark Dionne

    I ran this around noon today. The original test case was fixed, but an additional test case that I learned was not fixed:
    env X='() { (a)=>\’ sh -c “echo date”; cat echo; rm echo
    (If it prints the date, there is still a vulnerability. It always prints an error message.)

    How do I get version 4.7 of bash? I assume that the “total patches” value would need to be greater than 39.

    • Mark Dionne

      I see that there are now 40 patches for bash 4.0 available. The new patch has this comment: “Under certain circumstances, bash will execute user code while processing the
      environment for exported function definitions.”
      Installing patch 40 seems to have fixed the “date” vulnerability.

      Note that I needed to install gcc.

      I needed 4.1.7, not 4.7. It is on the gnu site with 13 patches, including the 2 shellshock ones. There are also 4.2 (with 49 patches) and 4.3 (with 26 patches).

      • Mark Dionne

        Correction: the comment for the latest patch (number 40 for bash 4.0) was: “Under certain circumstances, bash can incorrectly save a lookahead character and
        return it on a subsequent call, even when reading a new line.”

      • Hi, Mark. Make sure you don’t confuse “version” with “patch level.” It’s my recommendation to always keep the same “version” of bash (2.0, 3.3, 4.0, 4,2, etc.) on your system, and then increase the “patch level” by applying patches that fix issues.

  • William

    Thank you so much for taking the time to explain all of this… I was able to patch 2 of my old servers by following your instructions!

  • Dim

    On F15 all patched and worked. Thank you!

  • Thomas Leow

    Just to remind those who patched before 26 Sep 2014 has to re-patch again. There is a latest patch dated 27 Sep 2014.

    • Great reminder, Thomas. There have been two new patches so far (40 and 41) since the original version of this article. I’ve updated the script (and article) to include them both. But until this exploit cools off, it’s a good idea to keep an eye out for new patches, and then re-run the build process with an updated “lastpatch” number in my patching script to build the latest version.

  • JT

    Seemed to work. Until I rebooted the server and it didn’t come back. Luckily I was testing on a copy of a cloud server so didn’t kill any of my production machines.

  • Danny

    I wasn’t looking forward to patching two old FC servers again and again! That script was perfect. Thanks for sharing!

  • David

    Great work on this thread!! I will be my continued goto resource for fixing Shellshock. I have run into one system that is giving me fits though. It’s an older Vmware ESX 3.5 server running RHEL 3. The issue YUM isn’t configured with any repos (insuffiicent server config – no servers found. Aborting) so I can’t figure out how to install ybacc and bison. Of course I tried to ‘make’ without it and get the yacc: Command not found error.

    Any help from this thread would be greatly appreciated. I promise I have exhausted a google search for this and only asked after several hours of research. I don’t want to hose the system by specifying a repo and updating the whole OS. I just want to fix this bash issue.

    Bash 2.05b.0(1) – release (i386-redhat-linux-gnu)
    Red Hat Enterprise Linux ES release 3 (Taroon)

    I downloaded bash-2.05b.tar.gz and patched with 001-010, but can’t get the last step done without yacc.


    • Hi, David. A couple things you might try come to mind. First, you could install a repo, install only byacc, and then disable the repo again setting “enabled=0” in its .repo file. You won’t update the whole OS that way. Or, you could try to find a byacc rpm somewhere like, install it using rpm -i and then try compiling bash again. Please let me know if either works.

      • David

        Thanks again. That was a nudge in the right direction. I haven’t heard of rpmbone. I was able to find an rpm for byacc that installed okay and then I was able to complete the ‘make’ of the patched bash.

        I’m not sure about how I would have added the repo, so I’m glad rpmbone’s version of byacc worked out. If anyone has tried adding a repo to RHEL 3 that works let me know how.

        For the record:
        byacc-1.9-15sls.i586.rpm works with RHEL 3 to compile bash-2.05b

        The download of byacc-1.9-15sls.i586.rpm is here:

        Summary (google help to drive traffic):
        Updating Vmware ESX 3.5 running Red Hat Enterprise Linux ES release 3 (Taroon) to latest patched version of Bash 2.05b0(1)-release (i386-redhat-linux-gnu) can be accomplished by downloading bash-2.05b.tar.gz and related patches. To make you will need to install byacc listed above.

        Note: VMware ESX 3.5 will not be patched via normal channels nor will RHEL 3 so this is the only way to do it.

        Cheers and thanks Steve.

        • Awesome. Glad to know you’re all patched up! 🙂

        • Tim Walton

          Specifically for David..when a lazy solution presents itself, I’m all up for it!
          You’ve done what I need to do: any chance you could proffer up your patched bash 2.05b executable so I can just swap it on my handful of ancient machines and can rest easy. I’d would be very grateful.
          Thanks and regards,Tim

          • t

            No response needed: I resolved it myself.

          • Were you able to build your own 2.05b binary?

  • HP

    Thanks for the thread.
    BTW, there’s a typo in the step3. ‘ybacc’ has to be ‘byacc’.

    And, I have an error when I’ve typed ‘./configure’.

    ./configure: line 25828: syntax error near unexpected token `fpurge’
    ./configure: line 25828: ` AC_CHECK_FUNCS_ONCE(fpurge)’

    Do you have any idea to resolve this error?

    Thank you.

    • Thanks – typo fixed. Try doing “yum install ncurses-devel” — if that fixes your fpurge problem, please report back and I’ll add it to the list of required packages in the initial step.

  • HP

    I’ve resolved my problem.
    I’ve used bash 4.3 not 4.0. (FC4 server)
    Thank you.

  • Sottos

    Thank you for the very kind article.
    I was able to hit safely patch GNU bash-2.05b patch-001 to 010, But is not correct version display : “GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)” .
    Header file after applying the patch also zero : patchlevel.h “#define PATCHLEVEL 0”.
    In addition , there is no problem at all operations .
    Thank you again .

  • THANK YOU! This saved me a ton of time and guess-work. The older servers are patched.

  • Andres

    We have a Centos 4.6 server , this manual update can be used in our case ?
    Thank you

  • Andres

    I reach to step 5. When try the step 6 ./configure (as a regular user) get this errors
    $ ./configure
    ./configure: line 91: no such file or directory
    ./configure: line 92: no such file or directory
    chmod: cannot access `’: No such file or directory
    ./configure: line 204: conf30230.file: no such file or directory
    ./configure: line 1013: config.log: no such file or directory

    Any ideas?

    • Hi, Andres. Not sure which version of the Bash source code you’re looking at. If you edit the “configure” file in the source code directory, what does line 91 say?

      • Andres

        Steve, I’m trying this for the Centos 4.6 version, with bash-3.0.tar.gz and patches on bash-3.0-patches/

        these are the lines:
        line 91: echo “#! /bin/sh” >conf$$.sh
        line 92: echo “exit 0” >>conf$$.sh
        line 204: echo >conf$$.file
        line 1013: exec 5>config.log

        Is optional run the ./configure as a normal user ?
        can I try again but this time as root ?

        Thanks for your help !!

        • Hi, Andres. It’s ideal to run as a normal user, but it’s also possible to run it as root. However, if permissions were an issue, you’d normally get some sort of “not allowed” or “not permitted” type of message, rather than a “not found” message.

          • Andres

            Ok, tried again as root, this time no errors shown.
            So continue with follow steps, and everything looks good
            bash –version
            GNU bash, version 3.00.19(1)-release (x86_64-unknown-linux-gnu)

            Apparently this fix only works for exploits 1, 2 and 3.
            Exploits 4 and 5 stills shows Vulnerable

          • Great job, Andres. And yes — so far, those last two exploits are still open (although they are less likely than the first ones). I’ll be keeping an eye out for new patches from GNU.

  • John Westerdale

    Thanks Steve. After running the multipatch script (which looks fine), I dont see anything changing the I hacked it before compilation.

    [email protected] $ bash -version
    GNU bash, version 2.05b.10(1)-release (i686-pc-linux-gnu)
    Copyright (C) 2002 Free Software Foundation, Inc.
    [email protected] $ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
    [email protected] $ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
    [email protected] $ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
    [email protected] $ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
    [email protected] $ cd /tmp; rm -f /tmp/echo; env ‘x=() { (a)=>\’ bash -c “echo date”; cat /tmp/echo
    cat: /tmp/echo: No such file or directory

    (this one is supposed to fail per )

    Any reason the patchlevel.h is not updated in the patch process?

    Thanks!! John W.

    • Hi, John. I just looked at the patches on the GNU FTP server for Bash 2.05b, and those patches don’t seem to reference the patch level at all. It looks like the first time “#define PATCHLEVEL” appears is in Feburary 2005 with the first patch of Bash 3.0. So it appears that Bash 2.05b won’t have any reflection of the patch level when you query the version. I’ll add that to the article. Thanks! 🙂

      • John Westerdale

        Found the place tp park the version info (sorry if this is not news!).
        [email protected] $ more patchlevel.h

        #define PATCHLEVEL 13

        then binary comes out with:
        [email protected] $ ./bash -version
        GNU bash, version 2.05b.13(1)-release (i686-pc-linux-gnu)
        Copyright (C) 2002 Free Software Foundation, Inc.

        At least it can be known!

  • Bob Haskell

    Steve, thanks for the article. For our FC11 system, the patched version of bash is now 4.0.41(1)-release (i686-pc-linux-gnu). It passes the first three exploits and fails the last two. Does this seem correct?

    • Hi, Bob. Yes. That’s the same as my FC12 system, for the time being. I’m hoping GNU pushes a patch to block those later exploits soon.

  • Wow. Successfully updated bash on a REALLY old Fedora 8 machine, using your instructions. Thanks!

  • Pingback: Is DD-WRT Vulnerable to the Shellshock Bash Bug? | Steve Jenkins' Blog()

  • Dan

    Just wanted to chime in and say a huge THANKS for this. I just patched my Fedora 10 install with this and seems to be working perfectly. Just an FYI – on my Fedora 10 install, the bash being run was located in directory /usr/local/bin and not /bin

    • You’re very welcome, Dan! And thanks for the additional info on the binary location for FC10. I’m sure that will be helpful for others patching the same system.

  • Thank you very much! With over 60 Fedora 14 development servers in our environment, you have helped us out tremendously.

  • HP

    Steve, I’ve checked with your suggestion but I’ve already installed “ncurses-devel”. Anyhow, I’ve finished update my FC4 server with bash 4.3.27.

  • Hi. Thanks for article.
    I patch and install bash 4.0 and 4.1 on my FC14 box. It fixes 3 of 4 bugs. But one doesn’t fixed. 🙁

    Try this check:
    bash -c ‘true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

    If you see "CVE-2014-7186 vulnerable, redir_stack" string – bug not fixed. 🙁

    Plz help fix this vuln.

    • Dmitriy: You are correct. GNU has not patched that vulnerability yet. I’ll be updating this post once they do.

  • Ferdine

    I have more than 30 Servers running in Fedora version 12-16. Can I copy the same bash file and update them in all those servers? will it work?

    • To be safest, I wouldn’t share the same binary between an FC12 and an FC13 (or 14, or 15, of 16) box. But I don’t see any problem with sharing the same binary among the exact same distros (build on one FC12 box, share among other FC12 boxes).

  • Dave

    Worked on my Fedora Core 5 box running bash 3.1 🙂 many thanks – I will get round to replacing it soon!

  • daniel

    Thank you!

  • Mike Schwager

    Thanks, nice tutorial!

  • thnx!! f10, f16 and f17 ok now!

  • Srikanth

    Hi, firstly thank you for your excellent blog, very well written and easy to understand.

    I updated bash version 4.1 on three Linux Servers without any issues. However when I followed the exact steps to update bash 3.2 on a old Linux Server I got stuck at the ‘make the new binary’ step. I see the following errors-
    * *
    * GNU bash, version 3.2.54(3)-release (x86_64-unknown-linux-gnu)
    * *

    rm -f shell.o
    gcc -DPROGRAM='”bash”‘ -DCONF_HOSTTYPE='”x86_64″‘ -DCONF_OSTYPE='”linux-gnu”‘ -DCONF_MACHTYPE='”x86_64-unknown-linux-gnu”‘ -DCONF_VENDOR='”unknown”‘ -DLOCALEDIR='”/usr/local/share/locale”‘ -DPACKAGE='”bash”‘ -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -c shell.c
    rm -f eval.o
    gcc -DPROGRAM='”bash”‘ -DCONF_HOSTTYPE='”x86_64″‘ -DCONF_OSTYPE='”linux-gnu”‘ -DCONF_MACHTYPE='”x86_64-unknown-linux-gnu”‘ -DCONF_VENDOR='”unknown”‘ -DLOCALEDIR='”/usr/local/share/locale”‘ -DPACKAGE='”bash”‘ -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -c eval.c
    rm -f
    gcc -DPROGRAM='”bash”‘ -DCONF_HOSTTYPE='”x86_64″‘ -DCONF_OSTYPE='”linux-gnu”‘ -DCONF_MACHTYPE='”x86_64-unknown-linux-gnu”‘ -DCONF_VENDOR='”unknown”‘ -DLOCALEDIR='”/usr/local/share/locale”‘ -DPACKAGE='”bash”‘ -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -c
    ./parse.y: In function âparse_matched_pairâ:
    ./parse.y:2905: error: âtflagsâ undeclared (first use in this function)
    ./parse.y:2905: error: (Each undeclared identifier is reported only once
    ./parse.y:2905: error: for each function it appears in.)
    ./parse.y:2905: error: âLEX_WASDOLâ undeclared (first use in this function)
    ./parse.y: In function âcond_termâ:
    ./parse.y:3293: error: âtflagsâ undeclared (first use in this function)
    ./parse.y:3293: error: âLEX_PASSNEXTâ undeclared (first use in this function)
    ./parse.y:3297: error: âqcâ undeclared (first use in this function)
    ./parse.y:3297: error: âchâ undeclared (first use in this function)
    ./parse.y:3299: error: âretindâ undeclared (first use in this function)
    ./parse.y:3301: error: continue statement not within a loop
    ./parse.y:3304: error: âretsizeâ undeclared (first use in this function)
    ./parse.y:3304: error: âretâ undeclared (first use in this function)
    ./parse.y:3308: error: continue statement not within a loop
    ./parse.y:3322: error: âlex_wlenâ undeclared (first use in this function)
    ./parse.y: In function âreserved_word_acceptableâ:
    ./parse.y:3851: error: âBAR_ANDâ undeclared (first use in this function)

    I cannot proceed any further. Any reasons?

    Thank you once again,

  • Greg

    When i run “make test” on RHEL4 boxes it gets stuck at the following:

    warning: some of these tests may fail if job control has not been compiled
    warning: into the shell
    warning: there may be a message regarding a cat process dying due to a
    warning: SIGHUP. Please disregard.

    CPU usage is very high (~95%). Any ideas why?

    • It’s ok, wait.

      • Greg

        Still going 130 mins later. The RH5 boxes I patched didn’t take very long at all.

        • This actually happened on one of my boxes, too. At 130 mins, I’d just CTRL+C out of the process. If the bash binary is there in your directory as a result of the “make,” you’re very likely good to go. 🙂

          • Greg

            Thanks for the reply. Unfortunately when running certain commands the shell would freeze, only way to get it back was to kill the bash process.

            I had to revert back to the snapshot I took of the VM before install.

            If anyone has any ideas I’d appreciate it.

  • Fedora 12 user here and I followed your steps and used this to test for the vulnerabilities:
    The issue I get is the output:

    Not vulnerable to CVE-2014-6271 (original shellshock)
    Not vulnerable to CVE-2014-7169 (taviso bug)
    ./shellshock: line 18: 22557 Segmentation fault (core dumped) bash -c “true $(printf ‘< /dev/null
    Vulnerable to CVE-2014-7186 (redir_stack bug)
    Test for CVE-2014-7187 not reliable without address sanitizer
    Variable function parser inactive, likely safe from unknown parser bugs

    I get that (core dumped) if I test it with your test as well. Any idea?

    # bash –version
    GNU bash, version 4.0.41(1)-release (x86_64-unknown-linux-gnu)

    I was at 4.0.38


    • Hi, Geoff. Yes – that is the expected result. As I said near the end of the article, the patches don’t cover all the known exploits yet. I’m hoping they’ll be release soon, at which point you can repeat these steps (but increase the lastpatch variable in my script) and have an even newer version.

  • Thank you. Mr. Steve. The multi patch script a made this so much easier. I was able to patch Redhat ES4, ES5 and Suse 11.2 .

  • jack glendening

    Patching RHEL3 with bash 2.05b, I needed to add “-k” to the curl command due to certificate authentication failure. The patch then did successfully update bash. Thanks for providing the detailed steps.

    • Hi, Jack. I’ve added the -k option to the script so that snag doesn’t catch anyone else. Thanks!

  • Big Thanks from my FC16 🙂

  • Sushil Bora

    Thank you very much, Mr. Steve.

    The blog and script are very helpful. I was able to resolve first 3 vulnerabilities on Fedora13.

  • Ed

    Hi, the system i’m trying to update hasn’t been update for ages and the guy who set it up has left, the server hasn’t got the latest RHN ssl and I’m unable to install new packages. I’m having trouble compiling as the make command is not installed, how can I compile it using the gcc compiler. I’m a Linux noob, I appreciate any help with this issue. Thnaks

  • Michael

    Great article and just what I was looking for. I never knew how these were made and now I do. This is and will be very useful for me.

    One thing though, I’d recommend (but happy to be corrected) changing the ./configure to

    ./configure –build=i686-redhat-linux-gnu –host=i686-redhat-linux-gnu –target=i686-redhat-linux-gnu

    This would tie in with the output from the original ‘bash –version’. Otherwise instead of i686-redhat-linux-gnu’ I ended up with i686-pc-linux-gnu’. Only a cosmetic issue I think.

    • Hi, Michael. You’re right in that it’s a cosmetic issue (your build will run fine like this), but if you check Step 2 of the article, you’ll see that I explain why your original build has “redhat” in the version — that means it’s the “official” build FROM the RedHat repos, and not a build FOR a RedHat system. The build you’re making isn’t an official “redhat” build, so it’s technically not accurate to call it such. Leaving it as simply “pc” denotes that it’s a manually compiled build. However, like you said, it’s a merely cosmetic issue, and you can name it whatever you like. You could even make it –build=i686-michael-linux-gnu. 🙂

  • Pingback: Shellshock Warning: Even after patching, your old vulnerable bash binary could be “resurrected” from memory | Steve Jenkins' Blog()

  • Anh-Tuan Hoang

    Dear Mr. Steve Jenkins

    Thank you very much for your article with the bash.

    I am newbie with Linux and it helps me alot in solving that problem with my old system.

    However, I have a server with following information:
    # cat /etc/*-release
    Red Hat Linux release 7.2 (Enigma)

    # bash –version
    GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
    Copyright 2000 Free Software Foundation, Inc.

    I cannot find the patches directory in your introduced link for the GNU bash version 2.05
    (I expected it should be “bash-2.05-patches/”).
    And so, I cannot process step 5 in this article.
    Should I replace version 2.05 by version 2.05b?
    Can you suggest any solution for this patch version?

    Thank you

    Best regards
    Anh-Tuan Hoang

    • Hi, Anh. Yes. Go ahead and use 2.05b. Download that source from GNU, and then your variables in the patching script should be set to be “2.05b” and “205b” and “10” — please report back your success! 🙂

      • Anh-Tuan Hoang

        Hi Steve Jenkins

        Thank you very much for your fast reply.

        I tried as your suggestion but I think I got failure as follow when running the
        ./ command
        % Total % Received % Xferd Average Speed Time Curr.
        Dload Upload Total Current Left Speed
        100 1132 100 1132 0 0 183 0 0:00:06 0:00:06 0:00:00 1132
        patching file lib/readline/bind.c
        Hunk #1 FAILED at 312.
        1 out of 1 hunk FAILED — saving rejects to file lib/readline/bind.c.rej
        % Total % Received % Xferd Average Speed Time Curr.
        Dload Upload Total Current Left Speed
        100 755 100 755 0 0 858 0 0:00:00 0:00:00 0:00:00 755
        patching file lib/readline/readline.c
        Hunk #1 succeeded at 604 (offset -81 lines).

        I used it with the tar file downloaded from

        Is that my mistake using two un-matched versions in this case? (2.05 and 2.05b)

        Best wishes
        Anh-Tuan Hoang

        • Ah, yes. You can only apply patches from exactly the same build. You can download the 2.05b source here: In most cases, you should’t try to move from one version to another, but 2.05b in place of 2.05 is the exception. 🙂

          • Anh-Tuan Hoang

            Hi Steve

            Thank you very much.
            I think I have some progresses.
            The first 3 Exploits can be passed but the last 2 are vulnerable.

            Tested results:
            Exploit 1.
            this is a test

            Exploit 2.
            cat: echo: ▒▒▒Τ褦▒ʥե▒▒▒▒▒▒ǥ▒▒쥯▒ȥ▒Ϥ▒▒▒ޤ▒▒▒

            Exploit 3.
            Thu Oct 2 01:39:11 JST 2014

            Exploit 4.
            CVE-2014-7186 vulnerable, redir_stack

            Exploit 5.
            bash: line 2: `x{1..200}’: not a valid identifier
            CVE-2014-7187 vulnerable, word_lineno

            I am sorry for the un-readable charactors.

            What should I do to solve the last 2 Exploits?
            Or Should I wait for the newly updated patches for version 2.05b?

            Again, thank you very much
            Anh-Tuan Hoang

          • Good job. And for the last 2, we all just wait. 🙁

  • Pingback: Shellshock: bash manuell patchen | slacc()

  • bn,j04

    thank you

  • Steve

    Thank you!!

  • Gene

    Thanks for a great tutorial! Updated bash on a Fed 7 machine running bash 3.2. Only issue I had was the subst.c file had duplicate “fifos_pending” entries in two places that horked the compile. But got those removed and things ran like a champ.

  • ceumezaki

    Great Post, updated bash on a Fedora 12, but after changing the /bin/bash i´m getting errors like “/etc/init.d/functions: command substitution: line 20: syntax error near unexpected token `)'”

    Do you know what is wrong?

  • ceumezaki

    I Solved using this

    CentOS 6.5 is based in F12-13-14 so, install the update of bash from centos repo bash-4.1.2-15.el6_5.2

    32 bit:
    64 bit:

    rpm -Uvh bash-4.1.2-15.el6_5.2.x86_64.rpm

    and done, no more bug.

  • Pingback: Eric Stone | Eric M. Stone | Eric Michael Stone | Random Thoughts, Whims and Fancies()

  • David

    HI Steve, good job on the post! Thank you!

    I’m having issues on RHEL3 (yeah, i know ) with bash-2.05b

    Here’s some info:
    #bash –version
    GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
    Copyright (C) 2002 Free Software Foundation, Inc.

    #cat /etc/*release*
    Red Hat Enterprise Linux ES release 3 (Taroon Update 9)

    # uname -a
    Linux 2.4.21-53.ELsmp #1 SMP Wed Nov 14 03:54:12 EST 2007 i686 i686 i386 GNU/Linux

    Here’s how I patched bash:

    cd /usr/local/src
    tar -zxvf bash-2.05b.tar.gz
    cd bash-2.05b
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    curl | patch -p0
    make test
    cp -f bash /bin/bash

    Everything works fine….until the reboot. o.O
    The system boots….however login prompt no longer displays my hostname….none of my passwords work….network is down….basically I cant get in be it SSH or physically….single user boot results in the same thing.

    I’m still investigating what could be the issue, my guess it has something to do with /bin/sh since I cant even boot the server in “single” mode.

    I’m wondering if you came across a similar issue.



    • lsj

      just do this: ./configure && make && sudo make install

      • Hi, lsj. I appreciate your feedback, however I don’t recommend doing as you suggest. Here’s why:

        “make install” will actually place your newly built bash binary as /usr/local/bin/bash. That might appear OK, since that location will likely take precedence in your path over the old location. However… your old vulnerable bash binary will still be in /bin/bash — with /bin/sh symlinked to that old location.

        Now I hope you see why I recommend manually copying your newly build binary to your existing bash binary’s location, because there’s no guarantee that “make install” will put it in the right place. And in my testing on my Fedora 12 box, it actually puts it in the wrong place.

        • David

          Indeed “make install” puts it in /usr/local/bin by default.

          To work around it I ran ./configure –prefix=/ && make && make install.

          This time it puts it in /usr/bin…but the problem remains. Nothing works after a reboot.

          • If you run the newly build binary from the command line (before a reboot), does the shell operate properly?

          • David

            Yes, I can get to /bin/bash…exploit checks come back clean…I even tried opening a new SSH connection, I’m able to log in prior to reboot.

            However when I try go to /bin/sh and then type “/bin/bash” server hangs..It’s difficult to track the issue since i’m unable to log in to server.

            Thanks for looking into this! Appreciate it!

          • Weird.

            If you do “ls -la /bin/sh” does it show “/bin/sh -> /bin/bash” as a symlink?

            And “which bash” is definitely “/bin/bash” ?

          • Also, and I’m being super nit-picky here, if you want to use the -prefix flag so you can do make install later, I’d personally do -prefix=”. The end result will be the same (it will end up in /bin), but you’ll notice from the install script output that it’s attempting to store stuff in //share. That extra slash comes from your -prefix=/. I thought about trying to explain in the article how to determine the correct prefix, and using make install instead, but there was too much potential there for people to get it wrong and have the new binary end up somewhere wonky, without them knowing. I could have explained how to test for it, etc… but I wanted to keep it as simple as possible. But for users who know what they’re doing, ./configure –prefix=” && make && make install will totally do the trick.

          • David

            Yes, /bin/sh is symlinked to bash and “which” reports bash being in /bin/bash. Thanks for the “prefix” tip, i can try it later, somehow I dont think results will differ.

          • No, results won’t differ. And I’m totally stumped as to what’s stalling the reboot. I’ll think on it more while I’m working today. Hopefully someone else also sees this who has also faced the same problem and fixed it.

  • Travis

    Patch version 42 for 4.0 is out and appears to fix the last 2 exploits.

  • Sixhammers

    Many thanks, Your post is the most compreheinsive I have seen on the Net. Patch my servers without the script and all went well.


  • Jim Treadway

    Thanks for the article. You might also want to look into applying the distribution-specific patches (for Fedora 12 for example the you’ll see “bash-2.02-security.patch”, “bash-2.03-paths.patch”, …, “bash-4.1-broken_pipe.patch”, etc. in addition to the “upstream” GNU patches).

    If you download the latest .src.rpm for your distribution you can use that as a base — download the additional patches (“bash042-XXX”) and then add a line for each “new” patch to the “bash.spec” file and rebuild the RPM.

  • Richard

    Followed all the steps unfortunately was not able to compile the source code ran into this:

    [[email protected] bash-4.0]# make
    cd . && autoconf
    configure:25828: error: possibly undefined macro: AC_CHECK_FUNCS_ONCE
    If this token and others are legitimate, please use m4_pattern_allow.
    See the Autoconf documentation.
    make: *** [configure] Error 1

    [[email protected] bash-4.0]# cat /etc/redhat-release
    Red Hat Enterprise Linux ES release 4 (Nahant Update 7)

    [[email protected] bash-4.0]# uname -a
    Linux 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:39:47 EDT 2008 i686 i686 i386 GNU/Linux

    Any ideas?

    • David

      Make sure that the current /bin/bash –version is the same as you’re compiling. As far I know rhel4 has bash-3.0.

  • Great job! We have four RHEL 5 servers and no longer have support subscription, just saved us $4000!

  • Teikweidi

    Hi, I updated my bash version for FC17 w/this article. Many thanks. After updating, I have found that my old ~/.bash_profile information is no longer available after logging into Gnome. I believe my ~/.bashrc is getting sourced, but I not my ~/.bash_profile. I am unsure why this would be – any suggestions on how to fix it?

    • Great posting and great site! I also have the same problem as Teikweidi after performing this bash update process on a FC14. Did you ever get this resolved?

  • Dan

    I built and patched bash according to your instructions above and it worked fine. The only issue I have is after I copy over the new bash and log out and log in, my .bashrc and .bash_profile was wiped out (deleted from system). I’ve tried this on 2 different linux, centos 6.5 and opensuse 11.3 with the same results.
    Any way to prevent this? I know I can copy and save the .bashrc and .bashprofile from every user first, but looking for a better way.


    • Dan: Hmm… You’re the second person to report something this. Can you please try an experiment for me? Re-do all the steps (start with a fresh untar of the source), re-run the multipatch script, but when it comes time to configure, do the following:

      ./configure -prefix=” && make && make install

      (that’s two single apostrophes as the prefix, not a quote)

      I want to see if running the install script vs. manually copying makes a difference. Thanks.

      • Dan

        Hi Steve,
        The issue is different than I thought but it might be the same as Teikweidi. When using opening a bash shell within linux, it doesn’t seem to sourcing ~/.profile or /etc/profile. So the prompt used to be @hostname~$ but now it is bash4.1~$ and all the $PATH is not set and there is no colors for folders.

        If I run source /etc/profile, then everything is set. Should bash be sourcing /etc/profile by default? I’ve tried on multiple opensuse 11.3 machine (mostly what we have) and its the same. Maybe fedora is sightly different.

        Running this has the same results
        ./configure -prefix=” && make && make install


      • Dan

        Oh and I stand corrected on centos, no issues here when upgrading with your method. suse might be sourcing the /etc/bash.bashrc and other config differently

      • Dan

        I noticed fedora has a ~/.bashrc that sources /etc/bashrc, suse doesn’t contain any .bashrc or .bash_profile in the home directory. they must have used some other method.

  • Great, worked fine for me.

  • Ferdine

    After updating the bash in fedora 20 using the same bash script we are not able to login into SSH. Getting the following error,
    [email protected]’s password:
    Permission denied, please try again.”
    Can you please help on how to overcome this?

    • With Fedora 20, you should just do “yum update bash” — you don’t need the manual steps.

  • Edenfuma

    Thank you Steve, this article saved our server, and our asses

  • Andy

    Many thanks, worked perfectly on Fedora13…..saved my weekend, only took about 20 mins

  • Thank you for showing me how to patch the bash on an old RHES3 server.
    Thank you for teaching me some new things along the way.
    Thank you for all you have done for us over the years……

  • Pingback: ShellShock love for OS X -

  • naveed

    Hi Steve, Thank you for your detailed instructions. I tried it on opensuse 12.1 that has bash 4.2, but build had no error and I compiled new binary bash to /bin/bash. Tested it after rebooting server and still got vulnerable output on first test:

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

    bash –version
    GNU bash, version 4.2.42(1)-release (x86_64-unknown-linux-gnu)
    Copyright (C) 2011 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later

    Do you have any suggestions ?

  • naveed

    Hi Steve,
    My issue is resolved. Sorry, I missed some of the patch updates.

    Thanks for all your help!

  • Hi Steve,
    Thanks for your tutorial. I tried on Centos 6 X64. that gas bash 4.1
    But I get stuck in the ./configure step, i got some error here :
    # ./configure
    checking build system type… x86_64-unknown-linux-gnu
    checking host system type… x86_64-unknown-linux-gnu
    checking for emacs… no
    checking for xemacs… no
    Beginning configuration for bash-4.1-release for x86_64-unknown-linux-gnu
    checking for gcc… no
    checking for cc… no
    checking for cl.exe… no
    configure: error: in `/usr/local/src/bashfix/bash-4.1′:
    configure: error: no acceptable C compiler found in $PATH
    See `config.log’ for more details.

    Could you help me, please .


    • Do “yum install emacs gcc”

      That should fix your problem. 🙂

  • Rich

    Hi Steve,

    Thank you so much for the post and the wealth of detail, as an utter Linux novice this has helped me patch four of the five listed exploits on a couple of old RHEL servers running Bash 2.05b.

    The only exploit that is still present is CVE-2014-7187, I don’t know if you or any other commenters has any feeling as to when this might be patched? I can see they are still patching exploits on an almost daily basis, as the latest patch was on the 5th Oct. 2014, I just wanted to get a feel for how long this might take.

    All the best.

    • We patched several Fedora Core 2 servers running Bash 2.05b and Fedora Core 6 running Bash 3.17 by following this instruction. Same as you, CVE-2014-7187 is the only exploit left.

      Thank you for the great instruction.

  • Steve

    After following these instructions on two Fedora 8 installs, both were still vulnerable. Running bash –version showed I had the latest version while the vulnerability checking script said I was vulnerable. What happened was that there were TWO bash binaries. One was in /usr/local/bin and one was in /bin. I copied bash to /bin per these instructions but the one that got updated was /usr/local/bin. I deleted /bin/bash and made a symbolic link to /usr/local/bin/bash and now it passes the tests.

    • Hi, Steve. Yes – that can happen, which is why it’s important to find out exactly where the current binary is stored (in Step 1) and then copy the new binary into that spot. I’m going to guess you did “make install” instead of manually copying the binary. That’s OK do to, but only if you manually set the “prefix” flag as empty when you configure. 🙂

      • Steve

        I followed the instructions exactly on two systems. “which bash” reported /bin/bash and I copied the new bash to /bin. But the vulnerability still existed when I ran the vulnerability tests. I did a “bash –version” and it reported 3.2.55 so I was confused as to why I was still vulnerable. I didn’t run make install and did not copy the executable to /usr/local/bin but that is where the new bash ended up. Could this happen if the original /bin/bash was a link to /usr/local/bin/bash? I didn’t check that with “file /bin/bash” first.

  • Hi,

    I followed the instruction and hit this error when running make:

    ./parse.y:2449:1: error: redefinition of ‘parser_remaining_input’
    ./parse.y:2439:1: note: previous definition of ‘parser_remaining_input’ was here
    make: *** [] Error 1

    any idea how to solve?

  • arcsyst

    I have the same problem as eujinn

  • arcsyst

    SOLVED: I deleted the entire bash4.x directory and started again, it worked second time so I must have corrupted something in my first attempt

  • Andreas

    Many thanks, worked perfectly on Opensuse 10.3.

  • Ryan Kang

    Dear. Steve

    Because of you
    Fixed an issue simply shellshock.

    Thank you very much.

  • JUDY

    Steve: Followed your steps and work!!!!!! Many thanks!

  • Pedro

    When I get to step 6, I encounter this problem:

    sudo ./configure
    checking build system type… i686-pc-linux-gnu
    checking host system type… i686-pc-linux-gnu

    Beginning configuration for bash-4.2-release for i686-pc-linux-gnu

    checking for gcc… gcc
    checking for C compiler default output file name…
    configure: error: in `/usr/local/src/bashfix/bash-4.2′:
    configure: error: C compiler cannot create executables
    See `config.log’ for more details.

    what config.log says makes no sense to me, because I don’t speak Linux. The patches were installed properly. I deleted the directory and went through the process of building it up again after this happened the first time only to reach the same error. Any ideas? Thanks.

  • Hi Sir,

    I have followed the instructions above and somehow it made my system[Fedora 16] not vulnerable. But after the procedure I reboot my system and I got errors on “ifconfig” and “service” commands, its says “bash: ifconfig: command not found…” bash: service: command not found…

    How can I Fix this?



    • Hi Guys,

      Its ok now. After browsing from the internet its just the “su -” command will do the trick.



  • Excellent How-To. You saved my day and servers 😉

  • Pingback: David Piniella | How to Manually Update Bash to Patch Shellshock Bug on Older Fedora-Based Linux Systems | Steve Jenkins’ Blog()

  • You rock – nice work!! Saved me a lot of time!!

  • With Steve’s help, yet another old RHEL3 server is sleeping better…
    Thanks /;^)

  • Rams

    Wow….You are awesome man…..I have been trying to find the patch for my Centos 5.5 server. Finally, able to fix it simply using script. Thanks alot…

    Special thanks to, Mike Marino………. you guys are really awesome…..


  • Ira

    It’s failing for me. Any suggestions?

    First, a listing of the script:

    [[email protected] BashFix]# cat


    Secondly, the failing results:

    [[email protected] BashFix]# sh
    : command not foundline 2:
    : command not foundline 7:
    : command not foundline 9:
    : command not foundline 11:
    : command not foundline 14:
    sudo: Please use single character options
    usage: sudo -V | -h | -L | -l | -v | -k | -K | [-H] [-P] [-S] [-b] [-p prompt]
    [-u username/#uid] [-r role] [-t type] -s |
    : command not foundline 17:
    3.00.15ng Bash Version:
    : command not foundline 25:
    : abbing Latest Patch for bash-3.0
    : command not foundline 30:
    ‘ line 55: syntax error near unexpected token `do
    ‘ line 55: `for i in `seq 1 $lastpatch`; do
    [[email protected] BashFix]#

    • Hi, Ira. I’d first check to make sure you don’t have any strange linefeed or character issues introduced by copying and pasting.

      I’d go right to my GitHub Gist for (link in the article), select the “Raw” option, copy the URL, and then use a wget of that URL to pull it down to your server. Then just make the file executable and let it rip!

      • Ira

        Perhaps I’ve got the script in the wrong directory?

        Here’s my current failing results in part:

        [[email protected] ~]# sh
        % Total % Received % Xferd Average Speed Time Time Time Current
        Dload Upload Total Spent Left Speed
        100 5156 100 5156 0 0 8827 0 –:–:– –:–:– –:–:– 5035k
        can’t find file to patch at input line 22
        Perhaps you used the wrong -p or –strip option?
        The text leading up to this was:
        | =================

        • Ira: As long as you’re in the directory where the source is uncompressed, it should work. Try going through the directions again VERY carefully, and don’t skip ANY steps.

  • uyen

    Great article! So clear and detailed. It works like a charm! Thank you very much

  • Any suggestions on how to fix bash 2.05b or upgrade bash for this kernel

    > uname -a
    Linux 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 i686 i386 GNU/Linux
    > bash –version
    GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)
    Copyright (C) 2002 Free Software Foundation, Inc.

    • Marcin

      Well, i did all exactly as said in article, except that i manually downloaded applied all patches for 2.05b. Provided auto-script didn’t work for me.

      • Marcin

        One more thing. It looks like exploit #5 still works on patched bash 2.05b (up to bash205b-013 ) 🙁

  • Gerry

    Brilliant – Thank you. I have 4 virtual servers CentOS 7 down to CentOS 4.
    CentOS 4 was not fixed even after using the rpm for bash-3.0-27.el4 which the Redhat advisory shows should have been a fix. But this method absolutely works a treat!

  • sergio

    very interesting article.
    I’m using fedora 12 and I have follows the steps.
    The problem is that I use i386 and not i686, and I can’t replace the architecture, because some programs runs on 32 bit.

    How can I do?

    Thanks for sharing and regards


  • Pingback: Linux下的diff和patch命令 | ASPIRE()

  • john bolene

    did you have anything on updating old linux for the ghost glib attack? (CVE-2015-0235)

  • Worked like a charm Steve. On an old Slackware 2.05b.0(1)-release. I can’t thank you enough for the article.

    • Awesome, Todd! Slackware 2.05b.0? Impressive! 🙂

      • I should have stated that as an old Slackware with a bash version Slackware 2.05b.0(1)-release. 🙂 But I have more to go and all so far have upgraded perfectly. Thanks again!