Somebody (I will get the name) at TW once described this (and coined the name as far as I can tell) but I haven't seen anything much about (at least by name) online. So here goes:
The Wormhole Anti-Pattern arises when each change on one end of your application (e.g. the Database) requires a corresponding change on the other end (e.g. you Web page) (and often all the layers in between) as if there was a wormhole that opened up and teleported those changes right through your pretty little architecture.
It seems to happen when the design encompasses many layers, but these layers are not there to abstract one functioning sub-system from the others so much as to simply separate it.
As Jon points out, distribution is a key component of a wormhole opening up. Its also ironic, because a big reason that system designers cite for doing all of this separation by layer is to insulate each one from changes in the other.
The best way to avoid wormholes? For one, don't separate the layers. If you don't have an explicit -- and specific -- benefit to include a separation then its a good bet you've over-architected the system.
Second, look for abstractions along the layering boundaries. The first guideline covers all of the cases where your app is just passing data through, so this one is for all of that behavior you have left. Move the behavior to the right layer, and leave the other layers to do their job. Patterns seem to get people in trouble here, so I am going to single that out: Patterns are guidelines, and descriptions of common system designs, not blueprints that you shoehorn your system into. If you have wormholes, and you aren't just doing data pass-through, chances are you've got behavior in the wrong layer, and are having to duplicate the data accordingly -- I don't care what the pattern book says.
Are there always going to be changes that will affect every sub-system? The answer is unfortunately, probably yes. But they should be the rare exception. If they are happening all the time, look to plug those wormholes.