Why are some CentOS 5 boxes still vulnerable to ShellShock after upgrading Bash?

I have two CentOS 5.10 boxen where I have upgraded bash to the latest version. However, in one of the boxes, bash is still vulnerable to CVE-2014-7169 (I am using the test from this ServerFault answer).

Any ideas on why one machine is OK and the other one isn't? What can I check for?

What I've checked already:

1- Ensure both machines are running the same OS (same output on both):

# cat /etc/redhat-release
CentOS release 5.10 (Final)

2- Ensure I have the same version of bash (same output on both):

# rpm -qi bash
Name        : bash                         Relocations: (not relocatable)
Version     : 3.2                               Vendor: CentOS
Release     : 33.el5_10.4                   Build Date: Thu 25 Sep 2014 08:58:19 PM UTC
Install Date: Sat 27 Sep 2014 02:07:07 PM UTC      Build Host: sclbuild-c5.centos.org
Group       : System Environment/Shells     Source RPM: bash-3.2-33.el5_10.4.src.rpm
Size        : 5235475                          License: GPLv2+
Signature   : DSA/SHA1, Fri 26 Sep 2014 02:11:39 AM UTC, Key ID a8a447dce8562897

3- Double check that the binary is OK signature wise (same output on both):

# rpm -V bash

(there was no output from this command, indicating the binary signatures checked out)

4- Check that the binaries are in fact the same versions (as suggested by Cyrus in the comments): (same output on both machines)

# rpm -qf /bin/bash
bash-3.2-33.el5_10.4

5- Check the size of the binaries

# ls -l /bin/bash    (Good machine)
-rwxr-xr-x 1 root root 801816 Sep 25 20:55 /bin/bash

# ls -l /bin/bash    (Bad/vulnerable machine)
-rwxr-xr-x 1 root root 768952 Sep 25 20:55 /bin/bash

Notice that the file sizes are different.

6- Actually test for the vulnerability

# ## on the good machine
# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

# ## on the bad/vulnerable machine
# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
Sat Sep 27 13:44:36 UTC 2014

Could be a false positive - Make sure the 'echo' file does not exist from an earlier test on your bad machine, then retest.

Failing that, could also be a false negative - Check you can touch a file on your good machine, then retest.