La idea clave: la inmensa mayoría de los hackeos de WordPress se remontan a un pequeño conjunto de vulnerabilidades bien conocidas — plugins y temas desactualizados, credenciales de administrador débiles, inyección SQL en código vulnerable, cross-site scripting y endpoints de XML-RPC expuestos — cada una con una solución específica y conocida en lugar de una vaga recomendación de "mejorar la seguridad".
Por qué WordPress es un objetivo tan común
WordPress impulsa una gran parte de todos los sitios web — W3Techs lo ha registrado de forma constante por encima del 40% de toda la web durante varios años seguidos. Esa escala es precisamente la razón por la que es un objetivo: una sola vulnerabilidad descubierta en un plugin popular puede explotarse potencialmente en decenas de miles de sitios que aún ejecutan la versión vulnerable, lo que hace que los ataques automatizados de escaneo masivo merezcan la pena para un atacante de una forma que un sitio hecho a medida rara vez justifica.
Este es un contexto importante porque replantea el problema correctamente: el propio núcleo de WordPress no es el punto débil en la mayoría de los ataques. Lo es el ecosistema de plugins y temas que lo rodea, junto con decisiones básicas de configuración que están totalmente bajo el control del propietario del sitio.
Plugins y temas desactualizados
La investigación en seguridad encuentra sistemáticamente que los plugins y temas desactualizados con vulnerabilidades divulgadas públicamente son el mayor vector de ataque individual para las brechas de WordPress — muy por delante de las vulnerabilidades del núcleo o de los ataques dirigidos y personalizados. Una vez que una vulnerabilidad se divulga públicamente (incluso cuando ya se ha publicado un parche), los escáneres automatizados empiezan a rastrear la web en busca de sitios que aún ejecutan la versión vulnerable en cuestión de horas.
La solución es sencilla pero requiere disciplina: activa las actualizaciones automáticas para plugins y temas cuando sea posible, elimina cualquier plugin que ya no se mantenga activamente (comprueba su fecha de "última actualización" en el directorio de plugins de WordPress), y revisa el historial de vulnerabilidades de los plugins nuevos antes de instalarlos mediante una base de datos como la base de datos de vulnerabilidades de WPScan.
Credenciales de administrador débiles o reutilizadas
Los intentos de inicio de sesión por fuerza bruta contra wp-login.php son un ruido de fondo constante en la web — bots automatizados prueban combinaciones comunes de usuario/contraseña contra cualquier sitio WordPress que encuentran, y una contraseña débil o reutilizada convierte ese ruido de fondo en una brecha real.
La solución: exige contraseñas fuertes y únicas para cada cuenta de administrador, activa la autenticación de dos factores, renombra o restringe el acceso al nombre de usuario "admin" por defecto si todavía se usa, y limita los intentos de inicio de sesión para ralentizar las herramientas automatizadas de fuerza bruta.
Inyección SQL en plugins vulnerables
La inyección SQL permite a un atacante manipular una consulta de base de datos a través del propio campo de entrada de un plugin — un formulario de contacto, un cuadro de búsqueda, un parámetro de URL — que no sanea correctamente lo que se escribe en él, exponiendo o alterando potencialmente toda la base de datos de WordPress, incluidas las credenciales de usuario.
La solución es en gran medida la misma que para los plugins desactualizados: las vulnerabilidades de inyección SQL casi siempre se encuentran en versiones específicas de plugins y se parchean rápidamente una vez reportadas, así que mantenerse al día con las actualizaciones cierra la gran mayoría de estos agujeros antes de que lleguen a explotarse en un sitio determinado.
Cross-Site Scripting (XSS)
El XSS permite a un atacante inyectar JavaScript malicioso en una página a través de un campo de entrada sin sanear, que luego se ejecuta en el navegador de cualquiera que visite esa página — pudiendo robar cookies de sesión de administrador o redirigir a los visitantes a un sitio malicioso. Los campos de comentarios, los formularios de contacto y los ajustes de plugins que no escapan la entrada del usuario son los puntos de entrada más comunes.
La solución: se aplica la misma disciplina de actualización, ya que las vulnerabilidades XSS suelen ser específicas de un plugin y se parchean rápidamente; un cortafuegos de aplicaciones web (incluido en muchos plugins de seguridad) añade una capa que puede bloquear patrones de inyección XSS conocidos incluso antes de que se aplique un parche.
Abuso de XML-RPC
La interfaz XML-RPC de WordPress, originalmente creada para herramientas de publicación remota, se ha convertido en un vector común para dos ataques específicos: intentos de inicio de sesión por fuerza bruta enrutados a través del método pingback para evadir la limitación de velocidad normal, y usar el endpoint XML-RPC de un sitio como amplificador en ataques DDoS contra otros objetivos.
La solución: desactiva XML-RPC por completo a menos que el sitio dependa activamente de un plugin (más comúnmente Jetpack) o de una app móvil que lo requiera — para la mayoría de los sitios, esto cierra una superficie de ataque sin ninguna desventaja funcional.
Permisos de archivo inseguros
Los permisos de archivos y carpetas demasiado permisivos — a menudo dejados en sus valores por defecto o relajados durante una solución de problemas y nunca restablecidos — permiten que un atacante que consigue cualquier punto de apoyo en el servidor modifique archivos del núcleo, plante una puerta trasera, o lea datos de configuración sensibles como las credenciales de la base de datos en wp-config.php.
La solución: la propia documentación de WordPress recomienda 644 para archivos y 755 para directorios como referencia segura, siendo wp-config.php idealmente el que debería estar aún más restringido, ya que contiene directamente las credenciales de la base de datos.
Tabla de referencia rápida
| Vulnerabilidad | Punto de entrada común | Solución principal |
|---|---|---|
| Plugins/temas desactualizados | CVEs conocidos y divulgados | Activar actualizaciones automáticas, eliminar plugins sin mantenimiento |
| Credenciales de administrador débiles | Fuerza bruta en wp-login.php | Contraseñas fuertes, 2FA, limitación de intentos |
| Inyección SQL | Campos de entrada de plugin sin sanear | Mantener los plugins actualizados a versiones parcheadas |
| Cross-site scripting (XSS) | Campos de comentarios/formularios de contacto | Actualizar plugins, usar un cortafuegos de aplicaciones web |
| Abuso de XML-RPC | Fuerza bruta por pingback, relé de DDoS | Desactivar XML-RPC si no se necesita activamente |
| Permisos de archivo inseguros | Mala configuración a nivel de servidor | 644 para archivos, 755 para directorios |
Una checklist práctica de refuerzo
- Actualiza todo según un calendario, no de forma reactiva — el núcleo de WordPress, cada plugin y el tema activo, idealmente con actualizaciones automáticas activadas para las versiones menores.
- Elimina por completo los plugins y temas sin usar, no solo los desactives — un plugin inactivo pero instalado con una vulnerabilidad conocida todavía puede explotarse en algunas cadenas de ataque.
- Exige autenticación de dos factores para cada cuenta con acceso de publicación o administrador, no solo la cuenta de administrador principal.
- Desactiva XML-RPC a menos que una integración específica y activamente usada lo requiera.
- Prueba los cambios de seguridad primero en una copia de staging, ya que pasos de refuerzo como cambios de permisos o desactivar funciones pueden romper ocasionalmente un plugin que dependa de ellos.
Mantenerse informado sobre nuevas vulnerabilidades
Bases de datos de vulnerabilidades como WPScan y Patchstack rastrean las vulnerabilidades de plugins y temas de WordPress recién divulgadas a medida que se publican, y muchos plugins de seguridad extraen datos de esas mismas fuentes para alertar a los propietarios de sitios cuando un plugin instalado tiene un problema conocido. Suscribirse a uno de estos feeds, en lugar de esperar a notar un problema después del hecho, es la diferencia entre parchear horas después de la divulgación y parchear después de que un escáner automatizado ya haya encontrado el agujero.
Errores comunes que llevan a una brecha
- Asumir que un plugin de seguridad por sí solo es suficiente, cuando no puede parchear retroactivamente una vulnerabilidad conocida en software desactualizado que aún se ejecuta en el sitio.
- Desactivar en lugar de eliminar los plugins sin usar, dejando código con vulnerabilidades conocidas presente en el servidor aunque no se esté ejecutando activamente.
- Reutilizar la misma contraseña de administrador en varios sitios de clientes, convirtiendo una sola credencial filtrada en una brecha en múltiples sitios.
- Ignorar el refuerzo de permisos de archivo porque se considera una tarea de configuración puntual en lugar de un elemento de mantenimiento recurrente.
- Restaurar desde una copia de seguridad antigua sin comprobar si también restaura una vulnerabilidad ya parcheada, deshaciendo una corrección anterior sin darse cuenta.
Para terminar
En resumen, las vulnerabilidades que realmente comprometen los sitios WordPress son un conjunto bien documentado y predecible — sobre todo plugins y temas desactualizados, además de credenciales débiles, inyección SQL, XSS, abuso de XML-RPC y permisos de archivo laxos — cada una con una solución específica y conocida en lugar de una vaga llamada a "ser más seguro". Actualizaciones constantes y un puñado de pasos de refuerzo concretos cierran la inmensa mayoría de los ataques reales, exactamente el trabajo de escaneo y documentación que nuestro plugin Erdo CRA Compliance está diseñado para ayudar a rastrear junto con requisitos de cumplimiento europeos más amplios.