WordPress XML-RPC attacks target the xmlrpc.php endpoint, most often to amplify password guessing through system.multicall or to misuse pingbacks. You should disable or server-block xmlrpc.php when nothing you rely on needs it, but keep it only after checking tools such as Jetpack, the WordPress mobile app, and older publishing integrations.
XML-RPC is not automatically evidence that a site is hacked. It is an older remote interface built into WordPress. The useful question is whether your specific site needs it, then whether its exposure fits the way you manage the site.
XML-RPC is a remote interface for WordPress
xmlrpc.php accepts specially formatted remote requests and lets an approved client perform WordPress actions without using the usual browser dashboard. The file normally sits in the WordPress root, alongside wp-login.php and wp-config.php.
Historically, XML-RPC supported remote publishing clients and services. It is still used by some installations for Jetpack connections, the WordPress mobile app, and certain publishing tools. A site can use XML-RPC even if the business owner never knowingly opens the endpoint, because a plugin or connected service may use it in the background.
That history is why a blanket answer is not quite right. Blocking the endpoint is sensible for many business sites, especially sites administered only in a browser that do not use the integrations above. But blocking it without a check can interrupt a mobile editing workflow, a Jetpack feature, or a third-party publishing connection.
Start by listing the people and services that publish or administer the site. Check whether anyone uses the WordPress mobile app, Jetpack, an external editorial tool, or a custom integration. If the answer is no, XML-RPC is usually unnecessary. If the answer is uncertain, test the connection in a staging environment when possible, or plan a short monitored test after blocking it.
Brute-force amplification is the main XML-RPC concern
system.multicall can package multiple XML-RPC method calls into one HTTP request. When it includes login-related calls, an attacker can try many username and password combinations inside one request instead of making one visibly separate request for each attempt.
That changes how simple rate limits behave. A firewall or plugin that only counts HTTP requests may see a low number of requests while WordPress processes many credential attempts. It can also make access logs look less dramatic than the amount of password guessing taking place inside each request.
This does not bypass a strong, unique password. It does make weak passwords and reused passwords more exposed. Review every administrator account, remove accounts that are no longer needed, and give each remaining user a long unique password. Turn on multifactor authentication where your chosen WordPress or identity setup supports it.
Protect the normal login page too. Disabling XML-RPC does not block wp-login.php, does not patch vulnerable plugins, and does not remove a malicious administrator account. Keep WordPress core, plugins, and themes updated, and remove inactive plugins and themes you do not need. The WordPress hardening checklist helps organize these routine controls.
If logs show repeated requests to xmlrpc.php, preserve the relevant log entries before making changes. Note the timestamps, client addresses, request volume, and whether the requests contain repeated method calls. A high request count alone does not prove a successful login or compromise, but it is a reason to check accounts, update the site, and apply a decision about the endpoint.
Pingbacks can be used to send unwanted traffic
XML-RPC also includes pingback functionality. A pingback is meant to let one site notify another that it linked to its content. An attacker can abuse this feature by asking many WordPress sites to send requests to a target, which can create unwanted traffic from legitimate sites.
Pingback abuse does not mean your WordPress files were changed. It can mean your site is being used as one participant in someone else's traffic attack. Your host may contact you about unusual outbound connections, or a security service may identify requests involving your xmlrpc.php endpoint.
Blocking XML-RPC at the server stops XML-RPC pingback requests as well as XML-RPC login methods. If you keep XML-RPC because a required service needs it, discuss whether that service needs pingbacks specifically. A security plugin, web application firewall, or host may offer a separate pingback control, but test any change against the workflow you are preserving.
Do not try to diagnose a possible compromise from one log line. Look for related signs: unfamiliar WordPress users, modified core files, PHP files in wp-content/uploads, new scheduled tasks, or unexplained redirects. If those appear, use a structured hacked WordPress first-hour checklist rather than changing random settings while evidence is still available.
Decide whether your site actually needs xmlrpc.php
The decision should be based on use, not on a generic rule. A small brochure site whose editors log in through the browser and do not use Jetpack or a mobile app often has no reason to leave XML-RPC available. A site that relies on one of those tools may need it.
Use this short review:
- Ask editors whether they use the WordPress mobile app or an external publishing client.
- Check whether Jetpack or another installed plugin documents an XML-RPC dependency for the features you use.
- Identify custom integrations, site-management tools, or older workflows that may send requests to
xmlrpc.php. - If there is no dependency, block the endpoint and verify the public site and dashboard afterward.
- If there is a dependency, keep it only as long as necessary, protect the associated accounts, and monitor access through your host or firewall.
Document the result. Web agencies benefit from recording which client sites need XML-RPC and why, because a future security change or host migration can otherwise break a legitimate integration with little warning.
Server-level blocking is the complete disable option
Blocking requests to xmlrpc.php in the web server or host firewall is the complete way to prevent the endpoint from being used. The server denies the HTTP request before WordPress loads, so XML-RPC methods, including unauthenticated methods and pingbacks, cannot run.
For an Nginx-managed site, an administrator can configure a rule for the exact /xmlrpc.php path that returns a denial response. For Apache, an administrator can apply an equivalent access-denial rule in the virtual-host configuration or, when the host supports it, an appropriate .htaccess context. A managed WordPress host or a web application firewall may provide a dashboard control for the same result.
The implementation must match the actual server. An Apache .htaccess change has no effect when Nginx is serving the request without Apache's override support. Some hosts also cache or proxy requests in ways that make a WordPress plugin rule less reliable than a host-side rule. If you do not control the server configuration, ask support to block /xmlrpc.php for the domain and confirm what response visitors will receive.
After blocking, test the normal public pages, dashboard login, any contact form or store workflow, and every remote tool you identified. Then check the server or firewall logs to confirm requests to xmlrpc.php are being denied. A 403 or similar denial is expected; a normal XML-RPC response is not.
The xmlrpc_enabled filter is not a full block
The WordPress xmlrpc_enabled filter is sometimes described as a way to disable XML-RPC. It is narrower than that description suggests: it disables methods that require authentication. It does not stop the web server from accepting requests to xmlrpc.php, and it does not fully remove unauthenticated XML-RPC functionality such as pingback-related behavior.
That makes the filter a limited application-level control, not a replacement for a server-level block. It may fit a case where you intentionally want some non-authenticated XML-RPC behavior but do not want XML-RPC authentication. It is not the complete answer when your goal is to stop XML-RPC exposure entirely.
Avoid adding a code snippet to a theme merely to toggle this setting. Theme updates or changes can remove it. If a developer chooses to use the filter, it belongs in a managed custom plugin or another update-safe location, with documentation of the reason and a test of any integrations.
When to get help
If you are unsure what depends on XML-RPC, logs show sustained attempts against it, or the site has signs of a successful intrusion, a review can separate normal traffic from a broader problem. Our WordPress security audit can assess the configuration, and WordPress hardening can help put the right server and account controls in place.