¿Qué es xmlrpc.php en WordPress, para qué sirve y cómo desactivarlo de forma segura?

¿Qué es xmlrpc.php en WordPress, para qué sirve y cómo desactivarlo de forma segura?

Fecha: 30/07/2025

Es posible que si en algún momento hemos utilizado la aplicación de WordPress.com o Jetpack, hayamos experimentado errores de conexión en algún momento y nos hayamos enfrentado al error 'No pudimos realizar una solicitud XML-RPC a su sitio web.', que fue muy habitual cuando a partir de la versión 3.5 de WordPress se habilitó XMLRPC por defecto.

Esto se debía principalmente a que la aplicación que intentábamos conectar (una de las más utilizadas y el principal motivo de este cambio en XMLRPC fue la aplicación de WordPress.com). Era externa a nuestro WordPress y necesitaba conectarse a través de XMLRPC con el mismo.

Índice del artículo

  • ¿Es seguro mantener xmlrpc.php activo?
  • Principales riesgos y ataques relacionados con el xmlrpc.php
  • Ataques de fuerza bruta
  • Abuso de PingBanks para DDoS
  • Cómo comprobar si xmlrpc está habilitado
  • Cómo desactivar o proteger xmlrpc.php en WordPress
  • Utilizar un plugin
  • Modificar fichero .htaccess

¿Qué es xmlrpc.php y para qué se utiliza en WordPress?

Si utilizas WordPress seguramente has visto en alguna ocasión el archivo xmlrpc.php. No obstante, dado que es un fichero que no suele utilizarse para escribir en el mismo, como sí puede ocurrir con el wp-config.php o el .htaccess, en ocasiones se pasa más por alto.

Aun así, este fichero cumple una tarea muy importante en nuestra web, ya que su principal función es permitir la conexión de nuestra instalación de WordPress con otras aplicaciones remotas, lo que nos permitiría por ejemplo publicar contenido, realizar actualizaciones o conectar la instalación con otros servicios (como Jetpack, uno de los más conocidos).

Es importante tener en cuenta que actualmente el protocolo XMLRPC se utiliza menos, ya que parte de las funciones han pasado a gestionarse actualmente con REST API.

¿Es seguro mantener xmlrpc.php activo?

Dado que xmlrpc.php se utiliza menos para algunas tareas, es posible que la primera opción que pensemos tras esto sería que simplemente se podría prescindir del mismo como parte de WordPress, no obstante, por ahora se conserva como parte del núcleo de WordPress por cuestiones de compatibilidad principalmente y porque algunas tareas aún lo requieren.

El fichero xmlrpc.php no supone un problema de seguridad en sí mismo, no obstante, sí puede utilizarse como 'puerta de entrada' para ataques a nuestra instalación, por lo que salvo que nuestra instalación por algún motivo específico requiera que esté activo por la configuración que tiene la web o las funciones que necesitamos utilizar, puede deshabilitarse para prevenir que se utilice de forma que afecte de negativamente a la instalación.

Principales riesgos y ataques relacionados con el xmlrpc.php

Ataques de fuerza bruta

El principal problema del uso de xmlrpc.php para este tipo de ataques es la utilización del método 'system.multicall', ya que permite enviar varias solicitudes en una única petición HTTP, lo que hace que estos ataques de fuerza bruta tengan mayor magnitud, al poder comprobar miles de contraseñas con 4 o 5 peticiones HTTP y que de esta forma, algunas herramientas de seguridad dependiendo de su configuración, no detecten esto como un intento de acceso por fuerza bruta (ya que es un número de peticiones reducido, pero realizando al mismo tiempo miles de comprobaciones).

Abuso de PingBanks para DDoS

Un pingback es una notificación automática entre blogs para avisar de que en un blog se ha realizado alguna mención al otro blog (siempre que ambas instalaciones tengan los pingbacks activos).

Actualmente, no se utilizan tanto como hace unos 8/10 años, por lo que es menos habitual hacer uso de ellos y, por tanto, también utilizarlos para este tipo de ataques a la web, e incluso gran parte de las instalaciones pueden tenerlo deshabilitado.

Podemos deshabilitar los pingbacks en la instalación para evitar que se haga uso de esta funcionalidad, si no los utilizamos, desde "Ajustes > Comentarios" desmarcar 'Permitir avisos de enlaces de otros blogs (pingbacks y trackbacks) en las nuevas entradas' e 'Intentar avisar a cualquier blog enlazado desde la entrada'.

No obstante, los pingbacks utilizan también XMLRPC y esto permite hacer una alta cantidad de peticiones desde diversas IPs, lo que dificulta, por un lado, bloquearlas y además ese número de peticiones podría afectar al servidor, que podría llegar a saturarse.

En este artículo puedes ver más información sobre los ataques DDoS: https://raiolanetworks.com/blog/ataque-ddos-todo-lo-que-necesitas-saber/

Cómo comprobar si xmlrpc está habilitado

Para comprobar si xmlrpc.php está habilitado en nuestro sitio web, tenemos principalmente 2 alternativas:

  • Utilizar herramientas web como https://xmlrpc.blog/, donde tendremos que insertar la URL de la web que queremos comprobar y, si está activo, obtendremos el siguiente mensaje (si no está activo, obtendremos un error 405 o 403). comprobar si xmlrpc.php está habilitado
  • Realizar una petición al fichero correspondiente: https://dominio.tld/xmlrpc.php (sustituyendo dominio.tld por el nuestro). En caso de que esté activo, obtendremos lo siguiente: petición al fichero xmlrpc.php

Si no está activo, la notificación será diferente (generalmente un 403 o un 404):

respuesta a xmlrpc.php no activo

Cómo desactivar o proteger xmlrpc.php en WordPress

Si no utilizamos ninguna función que dependa de xmlrpc.php, podemos deshabilitarlo en nuestra web.

Utilizar un plugin

Podemos hacerlo con un plugin como 'Disable XML-RPC-API': https://es.wordpress.org/plugins/disable-xml-rpc-api/, que desactivará xmlrpc automáticamente al instalarlo.

Esta es una alternativa muy interesante si utilizamos Jetpack, ya que incluye una opción para añadir una excepción para Jetpack.

xmlrpc.php opción para añadir una excepción para Jetpack

Si utilizamos Perfmatters por ejemplo, podemos utilizarlo también para desactivar XMLRPC desde el apartado 'General'.

En caso de que utilicemos algún plugin de seguridad específico, es aconsejable que revisemos también si cuenta con esta opción. En el caso de SolidSecurity (anterior iThemes Security) podemos hacerlo desde "Ajustes > Avanzado > Ajustes de WordPress":

deshabilitar xmlrpc.php desde SolidSecurity

Modificar fichero .htaccess

También podemos desactivar xmlrpc.php insertando el siguiente código en el .htaccess:

 

       Order Deny,Allow 

       Deny from all 

Esto nos evita instalar un plugin adicional, si ninguno de los que utilizamos permite esta función, aunque es aconsejable tener en cuenta que el fichero .htaccess es editable generalmente, por lo que si en algún momento se desconfigura este código, XMLRPC volvería a estar funcional en la web.

Mila Fernandez
Mila Fernandez

Formo parte del departamento de WordPress, apasionada de la lectura, tengo la habilidad de saberme diálogos de Harry Potter de memoria.

Artículos relacionados

Si te ha gustado este post, aquí tienes otros que pueden ser de tu interés. ¡No dejes de aprender!

Tenemos 52 comentarios en ¿Qué es xmlrpc.php en WordPress, para qué sirve y cómo desactivarlo de forma segura?
Avatar del autor del comentario

Chris

11/10/2015 a las 22:24

Mu bien explicado todo. Gracias.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/10/2015 a las 23:46

Muchas gracias Chris, me alegro de que te guste.

Un saludo.

Responder
Avatar del autor del comentario

David García-Pascual Albares

23/01/2016 a las 11:13

Hola Álvaro, sobre incluir el código en el archivo functions.php, cuando trabajas con un tema child, es en éste donde hay que incluirlo ? Gracias !!

Responder
Avatar del autor del comentario

Alvaro Fontela

23/01/2016 a las 18:29

Exactamente David, en el functions.php del tema activo.

Un saludo.

Responder
Avatar del autor del comentario

tiendasenchina

28/01/2016 a las 00:07

Muchas gracias por el tutorial Alvaro. Ahora solo me queda hacer las modificaciones pertinentes.

Un saludo!

Responder
Avatar del autor del comentario

Alvaro Fontela

28/01/2016 a las 00:51

Nada, me alegro de que te sirva.

Un saludo.

Responder
Avatar del autor del comentario

frank

17/07/2016 a las 03:20

Hola, gracias por el dato, voy a probarlo. Solo una duda, en el instructivo indica modificar el archivo wp-config.php y en la imagen están modificando el archivo wp-config-sample.php
Cual es entonces? O hay que modificar ambos?
Saludos y gracias de nuevo!

Responder
Avatar del autor del comentario

Alvaro Fontela

21/07/2016 a las 17:18

No, tienes que modificar solo el wp-config.php, lo que ocurre es que en el preciso momento no podíamos modificar el wp-config.php.
Corregiremos eso para que nadie se lie con esto.

Un saludo.

Responder
Avatar del autor del comentario

ESPORA

20/07/2016 a las 17:37

El metodo 1 me funcionó perfecto, gracias Alvaro :D

Responder
Avatar del autor del comentario

Alvaro Fontela

21/07/2016 a las 17:17

Nada, gracias a ti, me alegro de que te sirviera esta información.

Un saludo.

Responder
Avatar del autor del comentario

Santiago Gonzalez

17/08/2016 a las 14:25

Muchas gracias por este tutorial, esta explicado de forma clara y sencilla. Gracias por el aporte. saludos!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/08/2016 a las 18:55

Gracias a ti Santiago.

Un saludo.

Responder
Avatar del autor del comentario

Antonio Pulido

17/08/2016 a las 23:20

Muchas gracias por el tutorial, me sirvió de mucho!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/08/2016 a las 18:56

Gracias a ti Antonio.

Un saludo.

Responder
Avatar del autor del comentario

Modesto Cabral

03/09/2016 a las 05:49

Bloqueando ese archivo en robots.txt no sería otra opción?
Saludos

Responder
Avatar del autor del comentario

Alvaro Fontela

05/09/2016 a las 00:04

Hola Modesto, con el robots.txt solo bloquearías a los buscadores, no a los bots malintencionados.

Un saludo.

Responder
Avatar del autor del comentario

ZfrenzyTv

06/09/2016 a las 06:25

Hola he usado el método 4 ya que estaba teniendo ataques y de hecho, aún usando el plugin, el consumo de cpu del server es bestial. También he bloqueado el rango de ips atacante. Alguna forma de evitar los ataques al servidor y que la cpu no se vea afectada?
Por cierto, estoy usando el Wordfence, que opinas de este plugin?

Responder
Avatar del autor del comentario

Alvaro Fontela

06/09/2016 a las 18:49

Hola, para mi Wordfence es el mejor plugin de seguridad para Wordpress y mas ahora que le han añadido el WAF.

Si quieres que los ataques no afecten al servidor, debes bloquear los ataques en el firewall del servidor (CSF por ejemplo) o en el firewall de red si tienes esa posibilidad.

Un saludo.

Responder
Avatar del autor del comentario

sinEntradas

11/09/2016 a las 18:34

Hola, llevo unas semanas que cada día se cae el servidor una o dos veces debido a este problema. He utilizado diferentes métodos y aun habiendo deshabilitado el fichero xmlrpc.php, encuentro en el log de apache peticiones "random" a ficheros inexistentes que terminan por tirar el servidor.

Y aún devolviendo un 500 las peticiones a xmlrpc.php el uso de cpu se disparaba por lo que volvía a caerse el servidor.

Estoy utilizando un vps en digitalocean y seguido varios de sus tutoriales pero sigo sin poder mitigar la amenza. También vengo utilizando cloudflare y creo que, a raíz de que llegara al tope en la tabla que tienen en su versión gratuita donde añaden ips amenzantes en su firewall, ha sido cuando he empezado a tener este tipo de problemas, a pesar de haber quitado bastantes reglas para que puedan volver a añadirse de forma automática como hasta ahora venía haciendo y habiendo metido estas de forma manual con ufw.

Voy a probar ese plugin a ver que tal es

Responder
Avatar del autor del comentario

Alvaro Fontela

12/09/2016 a las 15:35

Hola, si el servidor se cae en esta situación puede que el ataque sea muy fuerte o que el servidor no este correctamente optimizado.
Nosotros trabajamos con fail2ban y con reglas propias para mitigar este tipo de ataques, de esta forma los ataques no llegan a ejecutar PHP y por lo tanto no saturan el servidor.

Un saludo.

Responder
Avatar del autor del comentario

Fabián Baptista

19/09/2016 a las 17:12

Capos!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:11

Gracias Fabian.

Un saludo.

Responder
Avatar del autor del comentario

Luca Paltrinieri

21/09/2016 a las 08:20

Muy interesante. Pero qué se puede hacer si se quiere utilizar un servicio - que no es jetpack - que necesita conectarse con este archivo? Quiero conectar mi blog con Postable (postable.io) y no puedo justamente porque en el hosting (raiola claramente ) hay una redirección puesta al archivo /xmlrpc.php

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:12

Hola Luca, contacta con soporte tecnico, creo que te podrán dar una solución basada en añadir una regla al WAF del servidor.

Un saludo.

Responder
Avatar del autor del comentario

Luca Paltrinieri

22/09/2016 a las 16:17

Gracias Álvaro.
De momento he quitado la redirección y he añadido uno de los plugins que comentas, dejando el acceso al archivo sólo para la cuenta del administrador. Y ahora el enlace con Postable funciona. Espero que la web siga siendo segura, aunque creo que sí...

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:38

Hola Luca, no te preocupes, seguira siendo segura, de todas formas si detectamos ataques los bloqueamos manualmente.

Un saludo.

Responder
Avatar del autor del comentario

ceci

29/09/2016 a las 12:47

xmlrpc.php
Me dice una herramienta de análisis que tengo este enlaçe roto. es decir... que la url no lleva a ninguna parte: Method Not Allowed405

Alguien sabe como puedo solucionar esto.

Muchas gracias

Responder
Avatar del autor del comentario

Alvaro Fontela

02/10/2016 a las 15:39

Hola Ceci, debes contactar con tu proveedor de hosting para solucionar el problema, también debes revisar si tienes algo bloqueando el XMLRPC.PHP para peticiones externas.

Responder
Avatar del autor del comentario

Romina Lima

27/10/2016 a las 12:08

Muchas gracias, muy bueno todos los artículos, realmente muy interesantes y siempre aportando contenido de forma accesible.
Me queda una duda sobre la protección a XMLRPC ¿Sólo con el método 4 se puede utilizar jetpack?
Además, los plugin dicen no recibir actualizaciones desde hace unos dos años ¿aún serán efectivos?

Responder
Avatar del autor del comentario

Alvaro Fontela

30/10/2016 a las 01:47

Hola Romina, el plugin del método 4 teóricamente debería dejar funcionar Jetpack, pero no lo he probado últimamente, en todo caso, si provoca un error, te enteras rápido, ya que va a aparecer un error de conexión con los servidores de Automattic en el panel de Jetpack.

Un saludo.

Responder
Avatar del autor del comentario

Romina Lima

01/11/2016 a las 19:58

Gracias!

Responder
Avatar del autor del comentario

Dany Aguilar

09/12/2016 a las 21:47

excelente articulo! instale el plugin y hace lo del .htaccess y coloca en allow las ip de jetpack asi que sigue funcionando sin problemas

Responder
Avatar del autor del comentario

Alvaro Hernández Hernández

16/12/2016 a las 14:52

Hola!!
Que opinas sobre bloquear xmlrpc.php desde mismo apache? El sitio que administro no usa xmlrpc en absoluto y después de un par de ataques que tiraron el sitio lo desactive mediante "deny from all" en la configuración del virtual host de apache. Fue la solución más rápida que pude ejecutar al momento (aunque sigue escribiendo logs en el fichero de apache que ya no afectan el performance del server) en lo que configuro fail2ban para bannear las ips atacantes.
Saludos!!

Responder
Avatar del autor del comentario

Alvaro Fontela

21/12/2016 a las 11:08

Hola Alvaro, si tienes acceso a la configuración de Apache es una opcion mas, y hasta mas afectiva, ya que cuanto mas "de raiz" es la solución, menos impacta en el rendimiento del servidor, aunque no todos los usuarios tienen los conocimientos o la posibilidad de implementar este tipo de soluciones.

Un saludo.

Responder
Avatar del autor del comentario

Ivan Arturo Jauregui

24/03/2018 a las 06:40

Hola me interesa implementarlo en Apache, cual serian los pasos a seguir?

Muchas gracias!

Responder
Avatar del autor del comentario

Héctor Luaces

08/05/2018 a las 08:59

Hola, Iván:

Puedes optar por usar el siguiente código para bloquear todo:



Order Allow,Deny
Deny from all

Si quieres usar algo más refinado, complicado pero con más control puedes usar ModSecurity.

Un saludo!

Responder
Avatar del autor del comentario

Franklin

26/05/2017 a las 11:31

Alvaro, me han gustado el método 2 ya que te da la opción de bloquer la ip de quien te ataca , pero aun me preocupa que quede bloqueado API que utilizo para comunicarme con otros servicios como Twitter, ¿no sé si estos se afectarían? te consulto antes de proceder. Ha ademas se que he recibido ataque pero hasta el momento no veo mayor afectación solo que mi hosting me dice que quien me ataca y ademas he visto que mi trafico incrementa, pero no se lo puedo atribuir al ataque porque esta dentro de mi crecimiento normal de trafico.

Responder
Avatar del autor del comentario

Alvaro Fontela

06/06/2017 a las 18:32

Hola Franklin, ¿lo notas a nivel rendimiento o en algo en especial? Si los ataques no te afectan, creo que puedes omitir los ataques.

Un saludo.

Responder
Avatar del autor del comentario

bloghws

16/08/2017 a las 19:25

Excelente dato, ese error me apareció recientemente en uno de mis sitios, no soy programador pero voy a intentar la primera opcion que la veo mas segura, porque estuve revisando los plugins pero no me parece buna idea cargar el sitio con plugins. Muchas gracias nuevamente por el dato, lo voy a poner en práctica.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/09/2017 a las 00:41

Muchas gracias por tus palabras y espero que te haya servido.

Un saludo.

Responder
Avatar del autor del comentario

javiesfer

28/08/2017 a las 00:14

Hola!, vaya tema. Tengo instalado el Pluguin Redirection, ya que hice la migracion desde Blogger, y en los reportes de errores 404s me aparece 1 intento de entrada a /xmlrpc.php, esto quiere decir que el pluguien redirection lo identifico como url no existente. Por eso me aventure a buscar de que se trataba este archivo, y me encontre con toda esta informacion que brindas en tu post.

Invetsigando un poco mas, encontre otra opcion que propone eliminarlo directamente al archivo /xmlrpc.php y agregar las siguientes lineas de codigo en el archivo functions.php

function removeHeadLinks() {
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');

y deshabilitar la funcionalidad XML-RPC de las opciones de Wordpress

Quisiera saber que tan efectiva y recomendable puede ser esta opcion, si el archivo no es utilizado para sacarle provecho.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/09/2017 a las 00:42

El problema es que si eliminas el archivo xmlrpc.php y bloqueas su funcionamiento, algunas funcionalidades de WordPress van a quedar descolgadas y no podrás instalar algunos plugins como Jetpack.

Un saludo.

Responder
Avatar del autor del comentario

Artur

05/05/2018 a las 03:29

Es mucho mejor plugin:

https://wordpress.org/plugi...

otro es deprecado...

Responder
Avatar del autor del comentario

Héctor Luaces

08/05/2018 a las 08:50

Hola, Artur:

En efecto, mucho mejor, ¡gracias por la recomendación!

Ahora mismo optamos por usar modSecurity para proteger nuestros hostings sin necesidad de plugins.

Un saludo.

Responder
Avatar del autor del comentario

Erickson Vásquez

26/06/2018 a las 19:29

Excelente explicación, yo no uso pingback y trackbacks, tampoco el plugin jetpack ¿Cual método me recomiendas?

Responder
Avatar del autor del comentario

Héctor Luaces

27/06/2018 a las 08:40

Hola, Erickson:

te recomiendo el primer método. Es rápido de usar y se mantendrá si en el futuro migras de hosting, cambias de tema o usas un servidor web distinto.

¡Cualquier cosa nos dices!

Un saludo.

Responder
Avatar del autor del comentario

Alex Vidal

31/03/2020 a las 17:21
Que método o plugin recomendais actualmente para bloquear los ataques por fuerza "bruta" y que siga funcionando las actualizaciones de los plugins por Automattic
Responder
Avatar del autor del comentario

Alvaro Fontela

01/04/2020 a las 18:36
Hola Alex, pues la verdad es que creo que para este tipo de cosas el único que sigue en pie y que no ha cambiado mucho es Ninja Firewall.
Responder
Avatar del autor del comentario

Hugo Vidal

17/08/2020 a las 01:40
Hola Alvaro, Excelente artículo, ya vi que no pasa de moda.
Yo uso el tema Newspaper con Divi, desde hace como un mes el uso de CPU y Mmemoria se disparó, he instalado un par de plugins y aún así no bajan los parametros. Aunque han disminuido algo los errores HTTP 5xx. El que más ocurre es el 503

Tengo instalados los plugins -Anti-Malware Security and Brute-Force Firewall y el WP-Cerber security, este segundo tiene una opción Desactivar XML-RPC - Bloquear el acceso al servidor XML-RPC (incluyendo pingbacks y trackbacks). Eso ayudaría a reducir los ataques?

Probaría pero no sé si el tema utiliza el XML-RPC o el mismo servidor. Qué me aconsejas?
Responder
Avatar del autor del comentario

Alvaro Fontela

17/08/2020 a las 09:24
Hola Hugo, y....la pregunta es...¿sabes seguro que es por el XMLRPC? Porque si no es de eso, igual lo estas empeorando con tantos plugins de seguridad...

Lo digo porque...actualmente los ataques al XMLRPC son casi inexistentes, hubo un BOOM, pero ahora han bajado mucho y los WAF de los servers los detectan al instante.
Responder
Avatar del autor del comentario

Natalia

01/03/2021 a las 16:09
Hola! Muchas gracias por el tutorial!
Tengo una duda que igual es un poco tonta pero, en el método 1 primero hay que cambiar el nombre del archivo xmlrpc, por tanto en el código siguiente que hay que añadir a wp-config y al functions hay que modificar el nombre por el que hemos cambiado o hay que dejarlo tal cual lo has puesto?
Es que me aparecen el siguiente error:
Use of undefined constant ‘xmlrpc_methods’ - assumed '‘xmlrpc_methods’' (this will throw an Error in a future version of PHP)
Responder
Avatar del autor del comentario

Alvaro Fontela

03/03/2021 a las 13:48
Hola Natalia, la verdad es que nunca he visto ese error, aunque tampoco te puedo garantizar que este código este funcionando, ya que es un post antiguo.

Te recomiendo un plugin como este: https://wordpress.org/plugins/disable-xml-rpc-api/
Responder