exploiter -> machine -> conduit (in this case, a web server) -> bash command through scripting language
but that doesn't really make sense to me. if it's in the header as a cookie header, in php that would require something like this:
$someVar = $_COOKIE['somecookiekey'];
this is a super fringe case, and wouldn't warrant this big of a deal. for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash.
otherwise the risk is super minimal, so I don't think it's a matter of making system/exec calls on user-supplied data.
Your "exec($SomeVar)" example is a standard, unsanitized-input-passed-to-command-line type bug.
Shellshock does something fundamentally different. Everything on the actual command line is irrelevant to shellshock.
What happens is that the child Bash inherits env vars from the parent (which is often the web server). The shellshock bug is that the ENV VARS THEMSELVES are evaluated by bash as instructions.
Your actual PHP or whatever can be fully up to best-practices, sanitizing cookies and inputs, etc., and still fall vulnerable if one of the server-set environment variables like HTTP_ACCEPT_LANGUAGE has a malicious payload and ANYWHERE in your code, a subsequent system() call deep within some imported module gets fired off.
You're confirming the suspicion that I had. To wit:
"for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash."
Not a buffer overflow, but if those headers are being fed upwards into bash, that's what we're both talking about.