WordPress is vulnerable to the attacks described in the pingback advisory. In testing, a single PC on a T1 connection was able to cripple two dual Xeon apache servers on separate 100Mb connection. This was accomplished by sending out multiple requests to server A specifying a sourceURI on server B that was a 1GB media file. This attack utilizes resources on server A and server B, but not the malicious users machine.

Additionally, WordPress does not sanitize the sourceURI before passing it to wp_remote_fopen(); This makes it possible to specify non-HTTP resources to be read such as local files or ftp sources. In particular, a malicious user can determine whether certain files exist on the local file system. For example, the following request would help determine the version of Linux being used:
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>/etc/SuSE-release</string></value>
</param>
<param>
<value><string>http://b.example.com/#p</string></value>
</param>
</params>
</methodCall>

If this file does not exist, fault 16 (source URI does not exist) will be returned and if it does exist it is likely that fault 17 (source URI does not contain a link to the target URI) will be returned. This works whether curl or the fopen() stream is used, only the uri has to be changed. This will not work if the webserver user can not read the file.

If the administrator has allowed automatic pingbacks to show up as comments, it is possible for an attacker to have system information display in that comment. For instance, an attacker could request a url on the host with the following text in it:
<title>example</title><a href="valid targetURI">text</a>

If that showed up in the apache access_log or error_log, and the webserver user had permission to read that file the above XMLRPC request, after determining the OS, could specify the log as the sourceURI. This would cause some of the log file to be displayed as a comment. The session file for PHP would be a good target.

Recommendations:
Upgrade to Wordpress 2.1. The original recommendations made to the WordPress security team can be found below. Please note that Wordpress still does not check the content type, however the timeout has been set to 10 seconds and as such the impact of binary files is minimized.

The local file issues can be resolved by ensuring that the URI scheme is HTTP. This also disallows other resources, such as ftp, from being read. In order to prevent overly large files from being retrieved, a reasonable timeout for curl and fopen should be set. Also, if content is missing a compatible Content-Type (such as text/xml) it should not be read as it can not be parsed. The attached patch is one possible solution to the issues described above. There are some more significant design problems, particularly with respect to pingback authentication. These are described in the pingback advisory and are not addressed here, as there has been no formal specification modification yet.