People in other threads were suggesting using bitmaps and perpixel collisions, but is it fast enough to handle i.e. 100 games simultaneously?
I think there is a middle approach here where you can use Client-Server, but you let your clients do all the hard work, and keep them in sync using an arbitrating server.
The basic premise is that instead of doing all the work on the server, you capture client input and broadcast it to all the other clients. This is the premise behind most RTS games (and people frequently mistake them as being peer-to-peer, where in fact one of the players runs a server inside their game instance).
Since Worms is turn-based, there are no real-time requirements, which gives you plenty of CPU time between turns to ship some packets. You can have the clients transmit their last frame state to the arbitrating server. If any of the clients has mismatching data, the game is out of sync and you can drop it completely.
This gives you several benefits:
You can have a lot of games running off of a basic machine, because it isn't doing any heavy lifting.
You still have a client-server architecture.
Cheating in a synced game like this is near impossible.
You can go so far as to store replays if you want to.
In the end, the way you implement the terrain breakage doesn't really matter. You can use bitmaps and stencils, or vector fields. It's handled on the client-side.