The point is that the scenarios are vast, so any such list is going to give a false sense of security.

For example, you work with Squid. If someone wrote a log parser that called some bash script with the content of the URL as an env var, you���d potentially have problems.

Same if someone wrote an auth handler that set the username in an env var and then called a bash script. This is perhaps unusual, but is reasonable - perhaps some 3rd party auth database provides scripts that can be used to authenticate users.

Given that, does Squid filter out all the possible ways to exploit this bug? It is unreasonable to suggest that the person who wrote the auth handler should have known that the 3rd party script was written in bash - perhaps they upgraded recently, and the vendor changed how something worked.

Worth noting, a quick scan of the source code suggests that Squid itself doesn���t use env vars to pass things to ���program��� handlers, which means Squid is not directly going to trigger this, which is handy.

These are some contrived examples, but, I think it illustrates the point. Upgrade bash and fix the core of the problem, don���t mess about patching stuff around it hoping you caught everything - and hoping you catch everything in the future.