id summary reporter owner description type status priority milestone component version severity resolution keywords cc focuses 35532 Additional Security for XML-RPC to Prevent High Server Load - Specifically Pingbacks own3mall "XML-RPC requests need additional security to prevent high system resource usage on web hosting servers. Under Discussion settings, there are two settings: Attempt to notify any blogs linked to from the article Allow link notifications from other blogs (pingbacks and trackbacks) on new articles Even with both of these settings disabled OR enabled, XML-RPC pingback POST requests received in small increments (say 4 requests per second) can overwork the server resulting in a Linux server load increasing from under 0.50 to anywhere between 5-15 from a single abuser targeting a single installation of WordPress. The processing required for handling these requests needs to be more efficient. Recently, several installations of WordPress on my shared web hosting server have been under attack with bogus pingback requests sent repeatedly many times per second. For some reason, the logic handling these requests is causing too much processing to happen on the server resulting in the server load heavily increasing until the exploiter's IP address is banned (via iptables) or the Disable XML-RPC Pingbacks plugin is installed ([https://wordpress.org/plugins/disable-xml-rpc-pingback/]). Asking all of my shared hosted users to install this plugin isn't a solution to this problem. It's merely a work-around. Here is an idea to keep the web server from working too hard to process these requests: Write a file when a pingback request is received with the name of {IP_ADDRESS}.txt which contains a timestamp. {IP_ADDRESS} being the IP address from the client sending the request (PHP can grab this easily). When a pingback request is received, we check to see if the file exists, and if it does, we check to see if the current timestamp is greater than the old timestamp + 60 seconds. If it's not, we do NOT process this request at all because not enough time has passed. If it is, we process the pingback and write the new timestamp to the file. If the file doesn't exist, we create the file with the current timestamp and process the request. Then, WordPress could run a ""cron"" like function like it does for updating WordPress to delete these files to cleanup every once in a while. This will limit a source to one pingback request per minute, which seems more than fair. File system operations are very fast and so are timestamp operations, so I could see this working. This would also prevent a single attacker or multiple attackers from having a noticeable impact on the server. This solution could also be implemented database side assuming this isn't the reason for the high server load in the first place (initialization of the database). Please see these two topics for additional details (including packet captures) of how this problem is affecting a lot of installations: [https://wordpress.org/support/topic/wordpress-moderators-censoring-not-caring-about-important-security-issues?replies=20] [https://wordpress.org/support/topic/wordpress-44-xml-rpc-exploits-still-not-fixed?replies=25&view=all] I think this is an important issue that needs to be addressed. " enhancement closed normal Pings/Trackbacks 4.4.1 minor wontfix