Only recently did a new type of vulnerabilities turn up. The problem mostly affects X11 terminal emulators: rxvt, urxvt, eterm, et cetera.
The developers of these terminals thought they would be clever and choose the most widely deployed X11 display – «:0» – in case the DISPLAY variable is not set and no -display parameter is given.
This might be an improvement for the user in some corner cases, but it does indeed constitute a security risk. If the user starts an X11 display which sets DISPLAY, or if the user sets DISPLAY himself, then the user controls which display to show the terminal on. The same applies if the -display switch is used directly.
If however the terminal chooses some display by itself if none is given, this might have undesired effects. For example, if the user uses the su(1) facility to change his user to root, the DISPLAY environment variable gets cleared. Let's now assume that the user forgot about this and attempts to start a terminal by typing
Now, rxvt will attempt to connect to the display :0, while the user's display might indeed be connected to e.g. :10, because he's only SSHing into a server with X11 forwarding.
Now, display :0 means that a connection is made to port 6000 on the local host – a port which can be bound by any user. Any user can now create a rogue X11 server which accepts connections and then sends arbitrary commands – e.g. to create a new account with the user ID 0.
Sure, this could also happen if the DISPLAY variable is set to a wrong value, or if a wrong -display flag is specified. But for this to happen, user interaction is required, while no interaction is required to connect to :0 through the built-in default setting.