I would argue that the bash security concern is not a bug.  It is
clearly a feature.  Admittedly, a misguided and misimplemented
feature, but still a feature.  

The problem is that it was designed 25 years ago.  Apache didn't exist
yet for five years!  Granted, the internet already existed, but it was
still a more confidential club.  Security in internet software and
protocols were often just not considered at all in that time, and
definitely not when developping a program such as a shell.

So, we're in the context of designing a unix shell, where subprocesses
are created and run in a casual and normal manner.  When creating a
new subprocess, environment variables can be used to pass some data
from the parent process to the child process.  In the case of bash, it
is a feature that has been wanted, to have some functions defined in
the parent bash process also be transmitted and defined in the child
bash process.  Using environment variables to pass the definition of
those functions is natural.  

Where the implementation slightly went beyond the specifications, is
that it also executes any command present after the definition of the
function passed in an environment variable.  Since it's usually the
bash program which generates the value of the environment variables
used to pass those functions, there's normally no further command.  

But in the context where bash was designed, if a user added commands
to such environment variables, it could be still considered a
feature. In any case, the child process is executed on behalf of the
user who configured the environment variable, so there's no security
consideration to matter.

This feature is documented under the -f option of the export built-in
command.  The implementation detail of using an environment variable
whose value starts with "() {" and which may contain further commands
after the function definition is not documented, but could still be
considered a feature.

The problem is that 5 years later, new software was developed (apache,
dhcp, etc), that uses bash in child processes, and which still uses
environment variables to pass data.  Unfortunately, some of that data
comes not from the trusted user of the local system, but comes from
random users and program on the other side of the internet and of the
planet.  And in the meantime, the undocumented (and under-published)
feature of bash is forgotten.

It is an old precept for security on unix systems, that environment
variables shall be controlled by the parent processes, and an even
older and more general precept that input data shall be validated.

Assumedly programs like apache filter out environment variables
properly.  But unfortunately, in the validation of input data, they
fails to validate correctly input data because they don't expect that
data starting with "() {" will be interpreted by their bash child
processes.  If there's a bug, it's not in bash, but in apache and the
other internet facing programs that call bash without properly
validating and controlling the data they pass to bash.

 That said, there are some problems with bash, just as with most other
 software: it is lacking a specifications document, and it has
 undocumented features.

The problem we have is not a bash bug, but is basically similar to the
Ariane 5 bug: using a component from an earlier systems out of
specifications.

The reason why it's used out of specifications in this specific case
seems to be that there was no specifications written down, and no
documentation of the relevant implementation details.  But on the
other hand, it is free software and not difficult to check the source
to see as the nose in the middle of the face, what is done.  When
reusing a component with missing specifications and lacking
documentation, checking the source of the implementation should be
standard procedure, but it has clearly not been done by Apache or DHCP
developers.  

The bug is theirs, just like Ariane 5 bug IS NOT Ariane 4 bug!