A web application firewall logged an XML request to xmlrpc.php. Its body called system.multicall, selected wp.getUsersBlogs, and supplied a real WordPress username together with a guessed password. The alert identified the request in ModSecurity phase 2 and recorded it as a notice.
That is strong evidence of an automated authentication attempt. It is not evidence that the account was compromised, and the number 200 in the event does not prove that WordPress accepted the password.
This distinction matters because an administrator who misreads the alert may either ignore a real attack or respond with changes that break a legitimate integration.
What the request is trying to do
WordPress implements an XML-RPC server for legacy remote publishing and management clients. The official API includes methods for posts, media, comments, taxonomies, users and other administrative functions. wp.getUsersBlogs is an authenticated method: a client submits credentials and asks which sites are available to that user.
An attacker can use the same method as a credential oracle. A failed call and a successful call produce different XML-RPC responses, so a bot can try a username and a candidate password without using the normal login form.
system.multicall is a generic XML-RPC mechanism that packages multiple method calls in one HTTP request. When it is accepted by the server, it can reduce the number of network requests needed for repeated attempts. The presence of both system.multicall and an authenticated WordPress method is therefore a useful detection signal.
The WordPress XML-RPC API documentation confirms that the endpoint exposes remote management operations, while the xmlrpc_call hook reference identifies wp.getUsersBlogs as a built-in authenticated call.
What the WAF alert proves—and what it does not
The request body proves that someone submitted the observed username and password candidate. It does not tell you where the attacker learned the username. Usernames can appear in author archives, REST responses, feeds, cached pages, old data leaks or previous login attempts. A known username should be treated as public information, not as a security boundary.
The event also does not, by itself, answer these questions:
- Did the WAF only log the request, or did it apply a disruptive action?
- Did the request reach WordPress?
- Did WordPress return an authentication fault or valid account data?
- Were there many other attempts from the same address or from a distributed set of addresses?
- Did the account later create a session, application password or administrative change?
Read the complete ModSecurity audit entry and the matching access log line. Check the rule action, final response, client address, timestamp, request identifier and any upstream log. Do not infer the outcome from the severity label alone.
Why an HTTP 200 can still be a failed login
XML-RPC commonly transports application errors inside an XML response. The HTTP layer can therefore return 200 OK while the XML body contains a fault such as an invalid username or password. Conversely, a WAF log can display a number associated with processing or the eventual response without describing the authentication result.
The reliable question is not “Was the HTTP status 200?” It is “What XML-RPC result did the application return, and was the request blocked before that result?” If response bodies are not logged, use the WAF action plus WordPress and authentication telemetry rather than guessing.
Containment decision: block, restrict or retain XML-RPC
First establish whether anything still needs the endpoint. A legacy mobile client, publishing integration or management service may rely on it. Record the dependency and test it before changing production.
If the site does not use XML-RPC, the clearest control is to deny requests to xmlrpc.php at the web-server, reverse-proxy or WAF layer. An Apache 2.4-compatible rule is:
<Files "xmlrpc.php">
Require all denied
</Files>
Place the rule in a configuration context supported by the host, then request /xmlrpc.php from an external system and confirm that the web server returns the intended denial. Also verify that the normal front end, REST API and scheduled jobs still work.
If a known integration needs the endpoint, consider a narrow source allowlist only when the client uses stable, documented egress addresses. An allowlist based on an address that changes unexpectedly creates an availability problem. If stable source restriction is impossible, retain the endpoint but add rate controls and authentication monitoring.
The misleading xmlrpc_enabled filter name
This common snippet is useful, but its scope is narrower than its name suggests:
add_filter( 'xmlrpc_enabled', '__return_false' );
WordPress states that the xmlrpc_enabled filter disables XML-RPC methods that require authentication. It does not fully turn off the XML-RPC server, and it does not control pingbacks or custom unauthenticated methods. Use it when disabling authenticated publishing methods is the intended policy; do not present it as proof that every request to xmlrpc.php has been removed.
For a full endpoint block, enforce the decision before PHP. For granular application-level control, review the registered methods and the integration’s actual needs rather than copying a blanket snippet.
Account response
If the candidate password in the alert resembles a real or previously used password, treat the account as exposed:
- Replace the password with a unique value generated by a password manager.
- Revoke active sessions and review application passwords or other remote credentials.
- Inspect recent administrator, plugin, theme and user changes.
- Enable multifactor authentication for interactive login.
- Verify whether the chosen multifactor plugin also covers every remote authentication path you retain.
Multifactor authentication protects the paths on which it is enforced. Do not assume that adding 2FA to wp-login.php automatically changes XML-RPC behavior. Test the endpoint or disable it.
Changing the public display name may reduce accidental username disclosure in some templates, but renaming an account is not a substitute for a strong secret and endpoint controls.
Rate limiting and WAF policy
A single permanent IP block is rarely a complete response. Credential attacks rotate addresses, use compromised systems and return later. A better policy combines:
- a specific endpoint decision for
/xmlrpc.php; - request-rate or authentication-failure controls;
- a WAF rule whose blocking action is verified, not merely assumed;
- alert thresholds based on account, source and time window;
- protected log retention for later investigation.
Avoid a custom ModSecurity rule copied directly into production without checking the local rule engine, vendor rules, request-body limits and ID namespace. A syntactically valid rule can conflict with managed policy or block a legitimate integration. Implement it through the server’s supported customization mechanism, test it in detection mode, then confirm the disruptive response.
A compact investigation workflow
Use the following order whenever a similar event appears:
- Preserve the full event and correlate it by timestamp and request ID.
- Identify the method, username candidate and use of multicall.
- Confirm whether the WAF blocked, logged or passed the request.
- Determine whether the application returned a fault or valid data.
- Measure scope across accounts, addresses and time.
- Review the targeted account for independent signs of access.
- Decide whether XML-RPC is required.
- Block it completely, restrict it, or protect and monitor it according to that decision.
- Retest externally and watch logs after the change.
The practical lesson is precise: the log shows a credential attempt against a remote WordPress interface. Treat it seriously, but do not call it a successful login without application evidence. The strongest fix is not hiding the username or chasing one address; it is removing an unused authentication surface or governing a necessary one with verified controls.
Related Guides
For preventive filtering at the WAF layer, read Blocking Bad Bots with ModSecurity on cPanel and LiteSpeed. When a legitimate publishing request is blocked during hardening, follow the narrower procedure for diagnosing WordPress and ModSecurity 403 errors.