La seguridad en WordPress en 2027 se reduce a una lista corta de hábitos: mantener actualizados el núcleo, los plugins y los temas, blindar los accesos con contraseñas robustas y verificación en dos pasos, eliminar lo que no usas y guardar copias de seguridad probadas fuera del servidor. Casi todos los ataques que salen bien contra una web WordPress entran por una de esas puertas abiertas, no por algún fallo exótico del propio WordPress.
Última actualización: 20 de octubre de 2026.
Esta guía repasa las principales amenazas, una tabla de soluciones con el esfuerzo que exige cada una, una checklist numerada de protección, las normas de la UE que afectan a tu web y qué hacer en las primeras horas después de un ataque.
¿Es seguro WordPress?
El núcleo de WordPress lo mantiene un gran equipo de seguridad, recibe por defecto actualizaciones menores automáticas y se revisa constantemente. Por sí solo es una base sólida. El riesgo viene de lo que se le añade y de cómo se gestiona: plugins y temas de muchos autores, cuentas de administrador con contraseñas débiles, versiones antiguas de PHP, alojamiento barato sin aislamiento entre webs y nadie vigilando.
En resumen: WordPress es tan seguro como la forma en que se construye y se mantiene. Una web ligera, con pocos plugins bien elegidos, software al día y accesos controlados, es un objetivo difícil. Una web con cuarenta plugins, cinco de ellos abandonados, y una contraseña de administrador compartida es un objetivo fácil. La diferencia rara vez está en la plataforma; está en el cuidado que la rodea.
En Odduel, agencia de creatividad y tecnología en Barcelona y São Paulo, creamos webs WordPress con nuestros propios temas de bloques y con los menos plugins posibles, en parte por velocidad y en parte porque cada plugin es código en el que tienes que confiar. Si estás planificando una web nueva, nuestro trabajo de diseño y desarrollo web empieza con esa pregunta: ¿qué necesita de verdad esta web para funcionar?
¿Cuáles son las principales amenazas de seguridad en WordPress?
Los ataques a WordPress son sobre todo automáticos. Hay bots que rastrean la web en busca de debilidades conocidas y las prueban en cada sitio que encuentran, así que la web de una pequeña empresa tiene las mismas probabilidades de ser sondeada que una grande. Estas son las cinco amenazas que más importan.
Plugins y temas desactualizados
Es la vía de entrada más habitual. Se descubre un fallo en un plugin, se publica una corrección, los detalles se hacen públicos y los bots empiezan a probar el fallo en todas las webs que no han actualizado. El margen entre la corrección y los primeros ataques puede ser corto. Los plugins abandonados son peores: nunca se corregirán.
Accesos débiles y contraseñas robadas
La página de inicio de sesión en `/wp-login.php` es pública en todas las webs. Los bots prueban contraseñas habituales y contraseñas filtradas de otros servicios (relleno de credenciales). Una cuenta de administrador con una contraseña reutilizada, o con el nombre de usuario por defecto “admin”, le da a un atacante la web entera sin necesidad de ningún fallo.
XML-RPC y otras puertas de entrada heredadas
XML-RPC es una interfaz antigua para publicar en remoto. La mayoría de las webs ya no la necesitan, pero sigue activada por defecto y permite a un atacante probar muchas contraseñas en una sola petición. Lo mismo ocurre con la lista pública de nombres de usuario en la API REST, que entrega a los bots la primera mitad de cada inicio de sesión.
Subida de archivos
Cualquier formulario o plugin que acepte archivos puede convertirse en una forma de colocar un script en el servidor. Si después el servidor ejecuta PHP desde la carpeta de subidas, el atacante tiene una puerta trasera. Los formularios de contacto con adjuntos, los perfiles de usuario y los plugins de medios son los sospechosos habituales.
Cadena de suministro
Un plugin de confianza puede cambiar de manos. Un nuevo propietario, o un atacante que se ha hecho con la cuenta del autor, puede publicar una actualización con código oculto que llega a todas las webs que la instalan automáticamente. Los plugins y temas premium nulled (pirateados) son por definición un ataque a la cadena de suministro: a menudo llegan con el malware ya dentro.
Amenazas, soluciones y esfuerzo de un vistazo
La tabla empareja cada amenaza con la solución que la cierra y una idea aproximada del esfuerzo que supone en una web típica.
| Amenaza | Solución | Esfuerzo |
|---|---|---|
| Plugins y temas desactualizados | Actualizaciones semanales, pruebas en staging, eliminar plugins abandonados | Bajo, continuo |
| Accesos débiles | Contraseñas únicas, verificación en dos pasos, límite de intentos de acceso | Bajo, una vez |
| XML-RPC y listas de usuarios | Desactivar XML-RPC y la lista pública de usuarios | Bajo, una vez |
| Subida de archivos | Bloquear PHP en las subidas, limitar tipos de archivo, analizar las subidas | Medio, una vez |
| Cadena de suministro | Pocos plugins de autores conocidos, nada de código nulled, revisar las actualizaciones | Medio, continuo |
| Servidor comprometido | Alojamiento aislado, PHP al día, firewall, permisos de archivos mínimos | Medio, una vez |
| Pérdida de datos tras un ataque | Copias de seguridad fuera del servidor, con versiones y probadas | Bajo, continuo |
Fíjate en que la mayor parte del trabajo exige poco esfuerzo. Lo caro de la seguridad en WordPress no son las soluciones; es la limpieza cuando se las saltaron.
Checklist de seguridad para WordPress en diez pasos
Usa esta checklist de protección en una web nueva antes del lanzamiento y en una web existente como auditoría. Síguela en orden: los primeros pasos cierran las puertas que más prueban los atacantes.
- Actualízalo todo. Núcleo, plugins, temas y PHP. Activa las actualizaciones menores automáticas del núcleo, prueba primero las actualizaciones de plugins en una copia de staging y fija un ritmo semanal para el resto.
- Elimina lo que no usas. Borra los plugins y temas inactivos, no te limites a desactivarlos. Sustituye cualquier plugin que lleve un año sin actualizarse.
- Revisa los roles de usuario. Da a cada persona su propia cuenta con el rol más bajo que le permita hacer su trabajo. Los editores no necesitan ser administradores. Elimina las cuentas de antiguos empleados y de agencias el mismo día en que se van.
- Activa la verificación en dos pasos. Hazla obligatoria al menos para los administradores. Añade contraseñas robustas y únicas, guardadas en un gestor de contraseñas.
- Limita los intentos de acceso. Pon un límite de peticiones a `/wp-login.php` en el servidor o en el firewall, y oculta los nombres de usuario en los archivos públicos y en la API REST.
- Desactiva XML-RPC salvo que lo necesite un servicio del que dependas, y desactiva la edición de archivos desde el panel (`DISALLOW_FILE_EDIT`).
- Guarda las copias de seguridad fuera del servidor. Diarias, con versiones, almacenadas en otro lugar y restauradas una vez en una prueba para saber que funcionan.
- Añade un firewall. Un firewall de aplicaciones web en el alojamiento o por delante de la web filtra los ataques conocidos antes de que lleguen a WordPress.
- Envía cabeceras de seguridad. HTTPS en todas partes con HSTS, más `X-Content-Type-Options`, protección contra el encuadre, una política de referencia y, cuando estés listo, una política de seguridad de contenidos.
- Elige un alojamiento que aísle las webs. Cada web con su propio usuario de sistema, PHP al día, PHP bloqueado en las subidas y acceso al servidor solo con clave.
La seguridad también forma parte de las comprobaciones del lanzamiento. Nuestra checklist QA web recoge las pruebas que conviene hacer antes de publicar una web, y la seguridad va en esa revisión junto a la velocidad, la accesibilidad y los formularios.
¿Cómo proteger una web WordPress con el alojamiento adecuado?
El alojamiento decide cuánto de la checklist puedes hacer de verdad. En un alojamiento compartido básico a menudo no puedes configurar cabeceras del servidor, bloquear PHP en una carpeta ni ver los registros. En un alojamiento WordPress gestionado o en un servidor bien administrado, sí.
Hazle cuatro preguntas al proveedor de alojamiento. ¿Cada web está aislada de las demás en la misma máquina? ¿Qué versiones de PHP ofrece y con qué rapidez pasa a las nuevas? ¿Las copias de seguridad se guardan fuera del servidor y puedes restaurar una por tu cuenta? ¿Hay un firewall y un límite de intentos de acceso a nivel de servidor?
Si las respuestas son vagas, el alojamiento forma parte de tu riesgo. La elección de la plataforma también cuenta: nuestra guía sobre cómo elegir un CMS compara WordPress con otras opciones cuando la seguridad y el mantenimiento pesan mucho.
¿Qué normas de la UE afectan a la seguridad de WordPress?
Dos leyes recientes de la UE se citan a menudo en los artículos de seguridad, y las dos suelen exagerarse. Esto es lo que dicen de verdad para una web WordPress típica.
El Reglamento de Ciberresiliencia
El Reglamento de Ciberresiliencia, Reglamento (UE) 2024/2847, fija normas de seguridad para los productos con elementos digitales que se comercializan en la UE. Sus obligaciones de notificación de fallos explotados activamente se aplican desde el 11 de septiembre de 2026, y la mayoría de las demás desde el 11 de diciembre de 2027. Se dirige a los fabricantes de software y de productos conectados, así que afecta sobre todo a las empresas que venden plugins o temas. Una empresa que simplemente gestiona su propia web no se convierte por ello en fabricante, pero saldrá ganando a medida que los plugins que compra queden sujetos a las nuevas normas.
NIS2
La Directiva NIS2 se aplica a organizaciones medianas y grandes de los sectores enumerados, como la energía, el transporte, la sanidad, la infraestructura digital y parte de la industria, a través de la legislación nacional de cada Estado miembro. Si tu organización está incluida, tu web forma parte de los sistemas que debes proteger y tus obligaciones de notificar incidentes van más allá de la web. Si no lo está, la NIS2 no se aplica a tu web.
RGPD
La norma que se aplica a casi todo el mundo es el RGPD. Una web WordPress que guarda envíos de formularios, cuentas de clientes o pedidos guarda datos personales, y una brecha en ellos es una violación de la seguridad de los datos personales. Eso trae un plazo claro, que se explica a continuación.
¿Qué hacer tras un ataque a una web WordPress?
La rapidez y el orden importan más que las herramientas. Sigue estos pasos cuando sospeches que la web ha sido comprometida.
- Contén. Pon la web en modo mantenimiento o desconéctala, y cambia las contraseñas de todos los administradores, de la cuenta de alojamiento, de la base de datos y de cualquier servicio conectado.
- Conserva las pruebas. Copia los archivos, la base de datos y los registros del servidor antes de limpiar nada, para poder averiguar cómo entró el atacante.
- Evalúa los datos personales. Averigua si quedaron expuestos envíos de formularios, cuentas o pedidos. Eso decide tus obligaciones legales.
- Notifica si es obligatorio. Según el artículo 33 del RGPD, una violación de la seguridad de los datos personales debe notificarse a la autoridad de control sin dilación indebida y, si es posible, en un plazo de 72 horas desde que se tenga constancia de ella, salvo que sea improbable que suponga un riesgo para las personas. Si el riesgo para las personas es alto, también hay que informarlas a ellas.
- Limpia o restaura. Restaura una copia de seguridad anterior al ataque, o reinstala el núcleo, los plugins y los temas desde fuentes oficiales y limpia la base de datos. No te fíes de los archivos que estaban en el servidor durante el ataque.
- Cierra la puerta. Localiza y corrige la vía de entrada, normalmente un plugin desactualizado o una contraseña robada, o el atacante volverá en pocos días.
- Vigila. Revisa los registros, los cambios en los archivos y los resultados de búsqueda en busca de páginas de spam durante las semanas siguientes, y solicita una revisión en Google Search Console si la web fue marcada.
Deja constancia por escrito de cada paso y cada decisión. El RGPD te pide documentar todas las brechas, incluso las que no tenías que notificar.
Preguntas frecuentes
¿Es WordPress seguro para la web de una empresa?
Sí, si se construye de forma ligera y se mantiene. El núcleo de WordPress tiene un equipo de seguridad propio y actualizaciones periódicas. La mayoría de las brechas vienen de plugins desactualizados o abandonados, contraseñas de administrador débiles y un alojamiento deficiente. Una web con pocos plugins bien elegidos, verificación en dos pasos, PHP al día y copias de seguridad fuera del servidor es un objetivo difícil para los ataques automáticos, que son la mayoría de las amenazas.
¿Cada cuánto hay que actualizar los plugins de WordPress?
Busca actualizaciones al menos una vez a la semana y aplica las correcciones de seguridad en cuanto se publiquen, porque los ataques suelen empezar poco después de que un fallo se haga público. Prueba antes las actualizaciones grandes en una copia de staging. Cualquier plugin que lleve un año sin actualizarse debería sustituirse, porque un plugin abandonado nunca recibirá una corrección.
¿Necesito un plugin de seguridad?
No siempre. Muchas protecciones, como el límite de intentos de acceso, el bloqueo de PHP en las subidas, las cabeceras de seguridad y un firewall, funcionan mejor a nivel de servidor o de alojamiento, donde detienen los ataques antes de que cargue WordPress. Un plugin de seguridad puede ayudar en un alojamiento que no ofrece nada de eso, pero no sustituye a las actualizaciones, a unos accesos robustos ni a unas copias de seguridad probadas.
¿Debo desactivar XML-RPC en WordPress?
En la mayoría de los casos, sí. XML-RPC es una interfaz antigua de publicación en remoto que pocas webs siguen necesitando, y permite a los atacantes probar muchas contraseñas en una sola petición. Desactívala en el servidor o con un pequeño ajuste, salvo que la necesite un servicio del que dependas, como una app móvil de publicación antigua. Compruébalo antes de desactivarla.
¿El Reglamento de Ciberresiliencia se aplica a mi web WordPress?
Normalmente no de forma directa. El Reglamento de Ciberresiliencia impone obligaciones a los fabricantes de software y de productos conectados que se comercializan en la UE, así que afecta sobre todo a las empresas que venden plugins, temas o software. Una empresa que gestiona su propia web no es fabricante por ese motivo, pero sale ganando a medida que los plugins comerciales tienen que cumplir los nuevos requisitos de seguridad.
¿En cuánto tiempo hay que notificar una brecha de datos en WordPress?
Si quedaron expuestos datos personales, el RGPD te obliga a notificar la brecha a tu autoridad de control sin dilación indebida y, si es posible, en un plazo de 72 horas desde que tengas constancia de ella, salvo que sea improbable que ponga en riesgo a las personas. Si el riesgo para las personas es alto, también tienes que informarlas. Documenta todas las brechas, las notifiques o no.
Si tu web ha crecido plugin a plugin, o no sabes quién la actualizó por última vez, una auditoría breve con la checklist anterior es el punto de partida; nuestra guía de desarrollo web explica cómo se planifica un desarrollo ligero desde el primer briefing. Si quieres una web WordPress segura desde el principio, consulta nuestro servicio de diseño y desarrollo web o cuéntanos tu proyecto.
Para seguir leyendo: Next.js o React para la web de tu empresa, Webflow o WordPress en 2027: cuál encaja con tu empresa, Cuánto cuesta el mantenimiento web y qué incluyen los planes.
