WordPress XML-RPC blocked: reconnect a client without disabling all security

Distinguish XML-RPC access from logging in through a browser

Your publishing client displays an XML-RPC rejection, a 403 error, or an authentication message while WordPress administration opens in the browser. These two paths do not necessarily use the same method or identity. A setting protecting interactive logins may also change access for an application that does not display a second factor.

The goal is an authorized client connection to the correct site, followed by a read or a controlled test draft. First confirm that this client actually uses XML-RPC. A REST integration, a connection through an intermediary service, or an external API key is not automatically repaired by opening xmlrpc.php.

On a self-hosted installation, the account must have the permissions needed for the action, and the site administrator must authorize this access method. On WordPress.com or a managed plan, follow the procedure supported by the platform and the client. In multisite, check the target subsite and the account’s permissions there, not just its existence in the network.

Preserve publications and access before testing

Pause the client’s automatic submissions and preserve its local drafts. Do not retry publishing several times to see whether the connection returns: the first attempt may have created content before a response error. Check posts and drafts in administration before resuming.

Record the client version, configured address, account used, time, and exact message. Keep credentials and tokens private. Back up settings before a security change. For a write test, use a copy with external effects disabled and an account suitable for the reference draft.

Keep an independent administrative session and your second-factor method available during diagnosis. Repairing a client should not lead you to disable all login protections. If a targeted rule must change, its previous value and owner must be known so it can be restored. Do not delete other application access credentials before identifying the one corresponding to the failing client.

Verify the exact endpoint address

Check the site settings in the client and the documentation for its connection method. XML-RPC normally uses the WordPress installation’s xmlrpc.php file. If core is in a subdirectory, this endpoint may differ from the public homepage address. Do not infer it from an old address remembered after migration. In Settings, General, the WordPress Address can help locate core: view this value without changing it for this diagnosis. A custom path still needs confirmation from the administrator.

Compare the domain, HTTPS, path, and any redirect. A link ending on an HTML login page or another domain is not the expected XML response. Do not send credentials to a new destination without confirming that it belongs to the site. The client must use the officially intended final address according to its discovery process.

1. Open the site configuration in the client without deleting its drafts.
2. Compare the address with the current installation and the client documentation.
3. Correct only the confirmed address, keeping the old value.
4. First retry a read or refresh without publishing.
5. If an unexpected redirect persists, fix its source before renewing credentials.

Do not confuse a GET visit with an XML-RPC call

Opening the file in the browser’s address bar usually sends a GET request. The message “XML-RPC server accepts POST requests only” may show that the endpoint is reachable that way; it does not prove that the client’s POST call passes the firewall or authenticates successfully.

A 403 rejection on GET does not by itself describe how the application’s POST is handled either. Keep the method, status, and response type. An HTML protection page and an XML response containing an authentication fault do not indicate the same failure layer.

The WordPress xmlrpc_enabled filter affects methods requiring authentication, including publishing. It does not necessarily disable every public method. A response to a public request can therefore coexist with disabled publishing. Do not conclude that a plugin misreports its state simply because a read test still receives a response. The comparison must match the type of access the client actually needs.

Make a bounded public call if a terminal is available

This optional check is for readers who already have curl. Replace the fictional domain and path with your site’s confirmed endpoint. The command below is written for a Unix-like shell. On Windows, open PowerShell, replace curl with curl.exe, and join the lines by removing the \ continuation characters; keep the single quotes. Do not copy it unchanged into cmd. It requests the method list without credentials or content creation.

The timeouts bound how long this check waits. Redirects are not followed automatically: if a different address is returned, verify it before another test. Keep the output private if it reveals environment information. No token or password should be added for this step.

Receiving an XML list confirms only this public response along this route. It validates neither authenticated methods nor the client account. An XML fault indicating an unknown method may simply mean that this public method was removed: it does not justify opening all of XML-RPC. An HTML rejection page or protection status requires checking the corresponding rule. If you have no terminal, the client’s record and the provider’s logs let you continue without installing a plugin just for this check.

curl -q --silent --show-error --include --connect-timeout 5 --max-time 15 \
  --header 'Content-Type: text/xml' \
  --data '<methodCall><methodName>system.listMethods</methodName><params/></methodCall>' \
  'https://exemple.invalid/xmlrpc.php'

Classify the result before changing authentication

If the client never receives the endpoint’s XML response, investigate the route first: an incorrect address, redirect, HTTP protection, firewall, or hosting block. Have the message and time correlated with the relevant layer’s logs. The number 403 in the application does not by itself tell you whether the rejection comes from WordPress or a service in front of it.

If an XML response reports rejected credentials, check the mechanism expected by the client and the site policy. A fault number inside an XML document is not automatically the response’s HTTP status. Keep these two pieces of information separate to avoid a server change that cannot fix the identity being used.

If login succeeds but a specific operation is rejected, examine the account’s permissions and the requested method. Do not immediately grant it an administrator role. Finally, if only one device fails, compare its version and configuration with the working device; an old session still valid on the other device does not prove that new access uses the same credentials.

Choose an identity compatible with the client and protection

A WordPress application password is revocable access tied to a specific user. It suits tools supporting this mechanism without disclosing the main password to them. It is not used to open an interactive login in wp-admin. The account retains its permissions: this secret does not automatically grant additional capabilities. Its name is a label, not a restriction to this client’s functions; therefore choose an account whose permissions actually match the need.

How it is transmitted depends on the protocol and client. WordPress supports its use with XML-RPC, but a protection layer may require a particular method. Check both sets of documentation before pasting the secret into a field named password. Some tools use delegated authorization or their own signature; do not replace their token with an arbitrary application password.

If the client does not support the access authorized by the site, choose an update or a compatible official workflow. Do not try storing a temporary second-factor code as a permanent password. Nor should you use a session copied from the browser to bypass the mechanism: it can expire and is not a maintainable integration configuration.

Create a dedicated application password when this approach is suitable

On a self-hosted installation, this approach requires HTTPS and access to the relevant user’s profile. Under Accounts or Users, Profile, look for Application Passwords. If the section is missing, check feature availability and site policy with the administrator. Do not force it on with a code snippet without understanding the setting that hid it.

Create access named precisely for the client and device. The secret is displayed only once; save it in the designated secret manager and enter it only through the client’s documented procedure. Keep the main password and second factor for their normal use.

1. Open the profile of the account actually used by the client.
2. Add an explicit name under Application Passwords, then generate this access.
3. Save the secret privately and configure the client according to its documentation.
4. Test a read before submitting any content.
5. If the test fails or is abandoned, revoke only this access from the same profile; do not delete those belonging to other integrations.

Examine Wordfence only if it already protects the site

In Wordfence, Login Security, Settings, the Disable XML-RPC authentication option rejects calls requiring authentication. Turning it off may be necessary for authorized use, but the decision must match site policy. Keep its initial value. The Require 2FA for XML-RPC call authentication setting is a separate control: do not toggle every option to obtain a connection.

The documentation describes application password use, including through the Authorization header for a compatible integration. Check that the client supports the chosen mechanism. Do not assume that a secret entered into any field automatically bypasses a second-factor policy.

You do not need to install Wordfence to repair another system. Check the plugin and version already present before following this menu: Wordfence Security and a different security solution do not necessarily share the same settings.

1. Record the current values in Login Security, Settings.
2. Have the required access method validated and change only the confirmed rule. Save the change, then reload the settings to check the retained value.
3. Retry a read with the compatible client.
4. If the test is unhelpful, immediately restore the initial value and save the rollback. Keep the second factor for interactive login enabled.

Fix only the server rule rejecting the legitimate call

If logs confirm a rejection before WordPress, the administrator must examine the affected path and POST method. A rule may block xmlrpc.php entirely, apply HTTP protection, or treat some request origins differently. Keep the rule’s exact text and context before changing anything.

The fix must authorize the required route according to site policy without removing protection for the entire domain. If the provider imposes a block that cannot be changed, the client must use another officially supported method. A partial opening is suitable only if origin, identity, and methods can be managed correctly; do not copy an old universal Apache rule into an unknown environment.

1. Have the rule identified in the layer that actually records the rejection.
2. Keep its value, scope, and owner.
3. Adjust only the authorized case, first on a copy or within the planned test scope.
4. Test the same client, then ordinary browsing.
5. If the change is unhelpful or too broad, restore the rule and choose the client’s compatible workflow.

Check permissions when login already works

Successful authentication does not guarantee permission to perform every XML-RPC method. The account may read some information yet be unable to publish, edit another author’s post, or submit a content type. Compare the expected action with what the same user can do in the affected subsite’s administration.

If the client chooses the wrong site or content type, correct that choice before increasing permissions. In multisite, an account may exist in the network without having the required role on every subsite. A site identifier sent by the client may also designate a different context from the one displayed on the first screen.

Assign only the role or capability needed under the site’s organization. Do not create a permanent administrator to test a simple read. Keep initial permissions and remove diagnostic permissions that are no longer useful. If the operation remains rejected despite the correct context, keep the method name and exact message for the client owner or the component adding this content type.

Validate a read and then a test draft on a copy

Start by refreshing content or performing another documented client read. Check that the correct items appear and that access uses the intended account. Compare logs from the same time to confirm that the POST reaches the expected service without the block silently moving to another layer.

If the need includes writing, next create a clearly identified draft on the copy, with external submissions disabled. Check its author, status, destination site, and content in administration. Do not publish on the real site to prove a connection. Before retrying, check that the previous draft does not already exist.

Also repeat a normal interactive login to confirm that its intended protections remain usable. Remove the test content and temporary access no longer needed. If the fix depends on a changed security rule, document its exact scope. An account connecting once does not validate every function advertised by the client; check the functions actually needed separately, without expanding permissions out of habit.

Remove test access and retain a compatible workflow

Once the client is restored, keep the name of its dedicated access, account, and protocol. Revoke only secrets created for abandoned tests. If a secret was shared in a screenshot or ticket, revoke that access and recreate it through the normal procedure; hiding it after publication does not remove the already-exposed copy.

If the site must keep XML-RPC blocked, check whether the client offers REST mode, delegated login, or another officially maintained method. That alternative must be configured and validated according to its documentation; renaming the endpoint address does not convert the protocol. Avoid leaving a temporary opening when the client ultimately uses another route.

For a future incident, keep the exact address, method, HTTP status, any XML fault, and time. Add the policy change preceding the failure without including a secret. This record distinguishes a transport block, incompatible authentication, and a missing permission. A lasting connection depends on agreement between the client and site protection, with a known rollback for each attempted setting.

Distinguish four pieces of evidence for a repaired XML-RPC connection

Keep four results separately instead of one overall “works” verdict.

If creation succeeds but the client reports a timeout, look for that draft before any retry. After modifying it, check its content in administration, then remove the reference item and revoke the test application access. You now have evidence distinguishing transport, authentication, capabilities, and actual results. Native profile features and a compatible client are enough; adding a plugin that “opens XML-RPC” is not a general requirement for repair.

1. Transport: the POST reaches the intended final endpoint, without a redirect to another domain or an HTML protection page.
2. Protocol: the client receives an interpretable XML-RPC response. An XML fault is still a protocol response; it does not yet mean the operation succeeded.
3. Identity and permissions: the client finds the correct site with the intended account and can perform the required read. Access to another subsite does not validate this one.
4. Writing: on the copy, a draft clearly named “XML-RPC Test — date” appears exactly once, with the correct author and draft status. Note its identifier before testing modification from the client.