XML-RPC policy
TL;DR
WP fail2ban lets you give XML-RPC a defined job. You can close it when your site has no use for it or choose a narrower access policy: admit Jetpack or known source addresses, or expose only pingbacks while limiting how often a caller can make your site contact another server.
The interface in modern WordPress is mature and extensively hardened, with little intrinsic risk. Your policy begins by deciding whether your site needs XML-RPC at all. If it does, you can decide which callers should reach it and which methods they should be able to use.
WP fail2ban Free already distinguishes ordinary XML-RPC authentication failures from multicall brute-force attacks and, when pingback logging is enabled, records pingback outcomes for fail2ban. Premium adds the controls that restrict the endpoint, maintains the Jetpack allowlist, keeps a persistent event history, and can capture raw requests for focused investigation.
Give XML-RPC a defined job
XML-RPC is an interface through which remote software can authenticate, publish, manage content, and request pingbacks. A site using Jetpack has a different requirement from a private integration with stable source addresses, a site that wants pingbacks, or a site that has no remote client at all.
WP fail2ban lets you describe the access your site needs instead of inheriting the same public endpoint as every other WordPress installation.
Some integrations that once used XML-RPC now use the WordPress REST API. Check their current requirements rather than relying on an old assumption that the endpoint must remain open.
Source allowlists and pingbacks-only narrow the interface in different ways. Jetpack and private integrations need a source-based policy that admits the XML-RPC methods they use; a site with no such client can expose only pingbacks instead. Do not combine the two policies: limiting XML-RPC to pingbacks also prevents an allowed full client from using the other methods it needs.
Close an interface the site does not use
If nothing on your site needs XML-RPC, Premium can block the endpoint. Every request is refused and becomes a hard-filter event that fail2ban can enforce at the host firewall.
Modern XML-RPC presents little intrinsic risk. Closing an unused remote interface still reduces your attack surface and avoids processing traffic that has no legitimate purpose on the site.
Admit the callers you know
Premium can recognise Jetpack's source addresses and keep their list updated automatically. Jetpack can continue to use XML-RPC while requests from the rest of the Internet remain blocked.
You can apply the same policy to a private publishing system, management service, or other integration with stable source addresses. The allowlist lets those sources reach XML-RPC; WordPress authentication still decides what they may do.
Keep pingbacks without opening everything else
Pingbacks use XML-RPC, but a site that wants them does not necessarily need the rest of the interface.
Premium can keep XML-RPC blocked while exposing only the pingback method. To verify a pingback, WordPress contacts the remote page that supposedly contains the link. When pingback logging is enabled, WP fail2ban Free records successful pingbacks as soft events and failures as hard events. A fail2ban jail using the soft filter can limit callers that repeatedly make your site send those requests while unrelated XML-RPC methods remain unavailable.
That does not make pingbacks risk-free. It is a practical compromise for a site that values them: preserve the feature, narrow the interface, and reduce how readily your server can be used in an attack on someone else's site.
More about allowing pingbacks responsibly.
Stop abuse inside an interface you keep
An allowed XML-RPC client can send several method calls inside one request. Attackers have used that facility to pack repeated login attempts into a single connection.
WP fail2ban Free counts the authentication failures inside the request. The second failure turns the request into a multicall brute-force event and stops it, giving fail2ban a hard signal rather than allowing the bundle to hide behind one HTTP request.
You can therefore keep the XML-RPC access your site needs without treating every request as a single indivisible event.
More about stopping XML-RPC multicall brute-force attacks.
Capture the request when an event is not enough
When unusual XML-RPC traffic needs closer examination, Premium can write the raw requests to a dedicated log with their source and timing. Routine investigations can continue to use the structured event history.
The full body can show the exact methods and values the client sent. It can also contain credentials or other sensitive data, so raw logging is a focused diagnostic control rather than a setting to leave on indefinitely.
More about logging raw XML-RPC requests.
Let WordPress define the event
Once a request reaches XML-RPC, WordPress knows whether authentication failed, several failures were bundled together, or a pingback succeeded. WP fail2ban preserves those distinctions as events rather than reducing them to traffic against one endpoint.
Your XML-RPC policy decides what belongs. A configured fail2ban jail can then enforce each signal according to its meaning.
Features
