It may be possible to mitigate by enforcing bash to use privledged mode.
install the bash debuginfo
$ sudo debuginfo-install bash
install systemtap
$ sudo yum install systemtap
Run this script.
$ nohup sudo stap -g -e ' probe process("/bin/bash").function("initialize_shell_variables") { $privmode=1 } '
This ensures that the bash privledged mode (the equipvalent of bash -p) is always enabled.
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
The above is an example when it is NOT affected. Testing for the new vulnerability There has been an update to the original post and Bash 3.2.51(1) is still vulnerable to a variation of the vulnerability, defined in CVE-2014-7169
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory
The above is an example when it is NOT affected. Force enabling privledged mode has side effects that some sysadmins may need to be aware of. Listed below is an extract from the bash man page.
-p Turn on privileged mode. In this mode, the $ENV and $BASH_ENV files are not processed, shell functions are not inherited from the
environment, and the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored. If the
shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, these
actions are taken and the effective user id is set to the real user id. If the -p option is supplied at startup, the effective user
id is not reset. Turning this option off causes the effective user and group ids to be set to the real user and group ids.
This script above is a temporary mitigation and will not persist between reboots.