rxvt

It's now patched in the main trunk and other branches. Will take some
time to deploy a new version, as I first need to check the other bugs...

OK, now I got it. It's a trivial change to rxvt...

For a better explanation of possible attack vectors, please see
http://article.gmane.org/gmane.comp.security.oss.general/122

The security risk is that you can accidently launch a terminal on an X
server which belongs to another user and as such giving this other user a
full shell which runs with your permissions.
Setting DISPLAY=:0 leads to the same result, but the difference is that
you have to do this explicitly.

The X server cannot do anything about this -- it cannot tell whether it
was your intention to spawn a shell on a foreign X server or pure accident.

Maybe I got it wrong, but I don't think that this is a security problem
generated by rxvt, it is rather a configuration/protection/hardening
problem of the X11 server itself.

How does the "security risk" change after applying this patch? Not at
all, because the very same user actually controls the environment and might
set DISPLAY=":0" manually, so there would be no difference to the former
case.

It is almost like blaming ssh to try to login to a remote site using your
local account name for the remote site (per default, as convenience) and
realizing that in some cases the remote account uses an empty password.
The problem would not be solved by changing the ssh-client to not use the
local username...

So the real issue here is taking security measures to protect the X11
Server from being hijacked, not rxvt trying to open ":0" in first place
which is pure convenience.