Well - I hope that this isn't implemented the way Jake Savin announced it on the radio-dev mailing list: http://groups.yahoo.com/group/radio-dev/message/7946
The problem: for weblogs that don't yet have comment notification, it's quite easy to hijack the comment notification, even if option 2 from the email is used (option 1 isn't an option anyway because of its immutability).
The scenario is quite straightforward: since the setPrefs function doesn't just send the password (or rather its MD5 hash), but also all the data to query another server for validity, you can simply set up a small XMLRPC server that generally returns "ok, password is correct". You then include this in the setPrefs calls as the server to be queried. And just like that, you can use a loop to steal comment notifications from all numeric users on Userland. A classic case of not thinking things through far enough. It's quite astonishing how few people actually think about security and what it ultimately means. Too often you encounter half-baked solutions. Granted, comment notifications aren't really critical. But the function that's supposed to be protected here is called setPrefs - it's foreseeable that programmers will soon store additional settings there, and how these can then be set externally.
Where exactly is the error here? In communication with the server, that's clear. But the real error lies in the fact that a security-relevant area is implemented using a coupled system, where the coupling of systems is determined by the end user. And that last small part - determined by the end user - is the problem. System couplings in security-relevant areas must be pre-configured by the administrator; users may at best be able to choose from options. Because only the administrator can determine which sources are trustworthy for authorization. At Der Schockwellenreiter there's the original article.