This is a remote code exploit. For the web interface to do its job, it needs to be able to manipulate the wallet. They can stare at the code that does that, write their own, and do whatever they want.

Why does a web interface need to directly manipulate the wallet? It needs to store the transactions somewhere where the machine that executes them (using the wallet) can find them.

You need the seperation and you need to closely monitor and control the transactions requested from the web interface to detect any fraud or misuse.

Doesn't matter whether you do it directly or indirectly. There is some way of automatically manipulating money, and it will discover what it is.

I can dream up architectures which limit manipulations, require the user to constantly type in passwords, etc. A company not security conscious enough to update is unlikely to have done that. But suppose they did, what happens? EVEN THEN you can turn the website into the digital equivalent of an ATM skimmer, and steal money. That is, of course, assuming that I have not managed to turn shell access into some more direct compromise of your whole network.

Here is the moral. If you're directly handling money or a money equivalent on your website, and someone has shell access, they will be able to steal from you.

That's why you put velocity controls in place, so that if things go south you can limit losses. Coupled with alerting/reporting on transaction volumes and you should be able to get ahead of someone that bypassed your front end before they make off with all of your cash.

That said, if the backend is also vulnerable to the same or another exploit, that's not going to buy you much.

A secure bitcoin service provider should never manipulate the wallet directly, or in realtime. Transactions should be handled transparently, logged, and then actuall excuted on the offline wallet later after fraud and loss mitigation routines have been applied.