TL;DR XML-RPC
XML-RPC is a remote procedure call protocol that uses XML to encode its calls and HTTP as the transport mechanism. In WordPress, XML-RPC was the original way for external applications to communicate with a WordPress site remotely, allowing actions like publishing posts, managing comments, and uploading media without logging in to the WordPress admin interface. It was widely used by mobile apps and desktop blogging clients before the WordPress REST API became available as a more modern alternative. Today XML-RPC is largely unnecessary for most WordPress sites but it remains enabled by default, which creates a significant security problem. Attackers routinely target the xmlrpc.php file to carry out brute force attacks using a technique called credential stuffing, or to use the amplification method to execute DDoS-style attacks. CloudSonic's WAF blocks malicious XML-RPC requests by default, and for sites that do not need it, disabling it entirely through the WAF rules is a straightforward hardening step.
How XML-RPC Works in WordPress
XML-RPC in WordPress is implemented through a single file called xmlrpc.php located in the WordPress root directory. This file accepts POST requests containing XML-encoded method calls and returns XML-encoded responses. A request to publish a post, for example, would contain the method name wp.newPost along with parameters including credentials, post title, content, and metadata. The xmlrpc.php file authenticates the request by checking the provided username and password against the WordPress user database, then executes the requested method if authentication succeeds. The problem is that this authentication check happens on every request and the file is publicly accessible, meaning attackers can send thousands of authentication attempts per second to the xmlrpc.php file in an automated brute force attack. The multicall method makes this worse by allowing hundreds of authentication attempts to be bundled into a single HTTP request, amplifying the attack significantly. Blocking access to xmlrpc.php at the WAF level is the most effective mitigation.
