Unless you're using CGI, your system environment will not be contaminated. CGI is vulnerable because it relies on passing untrusted data in environment variables. No other gateway interface I'm familiar with does.

Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution.

Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environment, and the binary or the library ever invokes bash (e.g. via system()), then trouble will ensue.

Are you certain God doesn't exist?

This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables.

It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.

How does nginx pass data to passenger?

Edit: also note that CUPS is vulnerable according to https://access.redhat.com/articles/1200223

Also dhclient (!)

If you're using the nginx module, it gets the data from an instance of ngx_http_request_t. From there it gets passed around over sockets. Environment variables are not involved.

Using environment variables for request data would be quite insane when one of your marketing strategies is "fast" -- you'd either have to fork-per-connection just like CGI, or pre-fork processes that take input over a socket, deliberately deserialize it into the environment(!), and use getenv.

However overhyped Passenger might be, I don't know why you'd think the Phusion guys are that crazy.

Discovering that CUPS and dhclient may be vulnerable doesn't change anything. I'm talking about HTTP as an attack vector.