But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing.
Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge.
You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.
Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).
I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.
It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.
But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing.
Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge.
But as it is... I'm not sure?