The CSRF vulnerability in CentralAuth is still not fixed.
Copying from the «Bug 23076 strikes again» mail to private-l:
we created the hole with CentralAuth. The image loading is another login entry point, and it isn't protected by a cookie session nor can they easily be.
This is harder to exploit than bug 23076 or bug 23371, since the attacker can't give out the credentials on the malicious page and let the user autolog. The server would need to log in itself at request time and pass through the login image url it gets. At much, he could login different people on each domain. Tokens can only be used once and expire at 10 minutes so it needs to request a new one per victim. Note that this can't be fixed by just reducing the timeout.
Also, users already logged in are also vulnerable, being relogged into the new account.
In order to protect the image auto login token, Special:Userlogin should point with a token to a page on the target server which sets the login, redirects back with a session identifying token, then get redirected again to the real image at the target.
Since all wikis live in the same cluster, this last redirect could be skipped, with the original wiki setting the session for the target one. But it has to be carefully done. Otherwise the attacker could create a new session and attach itself to the user login.
Another option is to completely ditch image autoloading and have the user pass through Userlogin posting to a login server. If the user is logged there, it is redirected back logged in (you still need a token on that url). That has additional advantages, since it would solve "my wiki is not included" claims (bug 14407), skip third party cookies issues (bug 14736), autoaccount creation privacy (bug 19161) and all login actions could be performed by SSL (bug 12884).
On the other hand, now that users are used to automatic login almost everywhere, they may not be willing to press an extra button when they change projects.