Tienes Wordfence instalado, el escudo sale en verde y das el tema por cerrado. Lo entiendo, es lo que hace casi todo el mundo. El problema es que ese plugin solo ve una parte de lo que pasa en tu web. Y hay una capa entera, la del servidor, que el panel de WordPress te puede explicar mal.
Te lo cuento con un caso nuestro de octubre de 2026, con 130 webs de por medio. Pero antes, lo básico.
Por qué un plugin de seguridad no basta
Hace ya muchos años contaba en este blog que los ataques a WordPress son automáticos. Son programas que recorren internet buscando WordPress con un fallo conocido, a todas horas y sin mirar de quién es. Eso sigue igual. A tu web no la eligen: la encuentran.
Por eso un plugin de seguridad, por bueno que sea, es una pieza más. Bloquea intentos de entrada y te avisa de cosas raras, y está bien tenerlo. Lo que de verdad protege una web es un proceso que se repite:
- Actualizar lo que hay instalado.
- Hacer copias que se puedan restaurar.
- Vigilar lo que pasa.
- Comprobar que lo anterior se ha hecho de verdad.
El último es el que normalmente no tenemos en cuenta y por eso es el más importante. Y es que es justo en el número 4 donde el panel te puede engañar.
Qué hay que mantener al día en WordPress (y qué se olvida)
Lo que todo el mundo sabe que hay que actualizar son tres cosas: el núcleo de WordPress, los plugins y la plantilla. Si alguno lleva meses sin tocarse, empieza por ahí.
Con plugins y plantillas, una regla sin excepciones: solo de fuentes fiables. Nada de versiones piratas de un plugin de pago. Un plugin «gratis» que alguien ha retocado por su cuenta puede traer de regalo una puerta trasera, y entonces da igual todo lo demás.
Luego está la capa que casi nadie mira: la versión de PHP. PHP es el lenguaje en el que funciona WordPress, y no lo eliges tú, lo pone tu alojamiento.
Cada versión tiene una fecha de fin de soporte. PHP 7.4, por ejemplo, dejó de tenerlo en noviembre de 2022. A partir de ahí, si sale un fallo, nadie lo arregla.
Puedes tener WordPress y todos los plugins al día y que la web corra sobre un PHP sin soporte. Y el plugin de seguridad no te va a avisar de eso.
Lo vimos hace poco. En septiembre de 2026 medimos desde fuera las seis webs de un grupo de ingeniería industrial. Una seguía con PHP 7.4, casi cuatro años después de quedarse sin soporte. Y su versión sin «www» enseñaba un certificado de seguridad caducado en mayo de 2025.
Esto pasa cuando las webs se montan por partes. En aquel grupo había tres alojamientos distintos y dos proveedores de DNS (el servicio que dice a internet en qué servidor está tu dominio). Ni siquiera estaba claro quién gestionaba el servidor de una de las webs.
Cuando la versión de PHP que ves no es la que hay
Seguro que lo viste en las noticias. El 21 de octubre de 2026 se publicó una vulnerabilidad grave de PHP, conocida como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Afectaba también a versiones modernas de PHP, no solo a las antiguas. Al día siguiente revisamos las 130 webs que mantenemos.
El panel desde donde controlamos y monitorizamos las webs que mantenemos decía que solo 18 de las 130 tenían una versión de PHP con el parche. Leído así, era para echarse a temblar: más de cien webs abiertas.
Antes de tocar nada, agrupamos las webs por servidor. De las 82 pendientes con PHP 8.2 o superior, 75 estaban en solo dos alojamientos. El 91 %. Así que no hacía falta revisar 75 webs: hacía falta hacer dos preguntas.
Las respuestas fueron distintas:
- Una de las empresas de hosting confirmó por escrito, y en público, que había parcheado sus servidores. Había metido el arreglo en la versión de PHP que ya tenían, así que el número visible no cambiaba.
- La otra nos dijo que lo tenía mitigado con su cortafuegos y que estaba parcheando poco a poco. Mitigado no es parcheado: el ataque se frena delante, pero el arreglo de fondo todavía no está.
Lo que saco de esto: si me hubiera fiado solo del número de versión, habría tenido 75 avisos que no servían para decidir. En unas webs el número decía «vulnerable» y el parche ya estaba puesto. En otras había una protección provisional que el número tampoco reflejaba.
El error al revés: subir de versión y seguir siendo vulnerable
La segunda mitad del caso va en sentido contrario, y es la que más me preocupa, porque da una falsa tranquilidad.
En algunas webs, la reacción fue «hay que subir PHP» y se subió «a la 8.3». Quedaron en la 8.3.35, que seguía siendo vulnerable: el arreglo llegaba con la 8.3.36. En las otras ramas, las versiones corregidas eran la 8.2.35, la 8.4.27 y la 8.5.12.
Lo que hay que comprobar es la versión de parche, el último número, y no solo la rama. «Estoy en la 8.3» no dice nada. «Estoy en la 8.3.36 o superior» sí.
Hubo otra confusión. Teníamos en marcha un plan para subir las webs con PHP por debajo de 8.2, y parecía que ya cubría el problema. No lo cubría. «Por debajo de 8.2» era el criterio de fin de soporte, no el de esta vulnerabilidad, que afectaba también de la 8.2 a la 8.5 hasta su parche. Son dos preguntas distintas:
- ¿Mi versión de PHP tiene soporte? Si no lo tiene, hay que subirla, haya alarma o no.
- ¿Mi versión tiene el parche de este fallo concreto? Eso lo dice el aviso de cada vulnerabilidad, con sus números.
El plan de subir las webs con PHP 7.4, 8.0 u 8.1 siguió adelante, porque esas versiones no tienen soporte. Pero no era la respuesta a PHP2Shell.
Cómo comprobar la versión de PHP de tu web
Esto lo puedes hacer tú en cinco minutos, sin tocar nada:
- Entra en el escritorio de WordPress y ve a Herramientas → Salud del sitio → Información → Servidor. En «Versión de PHP» la verás con todos sus números.
- Cuando salga un aviso de seguridad, mira qué versión corregida publica para tu rama y compárala con la tuya.
- Si la tuya es igual o superior, bien. Si es inferior, no des por hecho que estás vulnerable: puede que tu alojamiento haya parcheado sin cambiar el número.
- En ese caso, pregunta a tu alojamiento por escrito: «¿Habéis aplicado el parche de este fallo en mi servidor, aunque no cambie el número de versión?». Y guarda la respuesta.
Por escrito, sí. Una respuesta por chat que nadie guarda no te sirve dentro de tres meses.
Y lo que no sabes también cuenta. En nuestro caso quedaron cinco webs con PHP 7.4 de las que todavía no sabíamos en qué servidor estaban. Si no sabes dónde está alojada una web, no sabes quién la parchea. Apúntalo como pendiente y no lo des por resuelto.
Copias de seguridad que se pueden restaurar
Una copia de seguridad que nadie ha probado a restaurar es una esperanza, no una copia. Puede estar incompleta, puede estar en el mismo servidor que se ha caído, o puede que nadie sepa cómo volver a montarla.
Lo mínimo que yo pediría:
- Que la copia se guarde fuera del servidor donde está la web.
- Que se haga sola, con una frecuencia que encaje con lo que cambias en la web.
- Que alguien compruebe de vez en cuando que se puede restaurar.
Si lees esto porque ya te han entrado, este no es tu artículo. Te explico los pasos en qué hacer si ya te han hackeado el WordPress.
Qué haría yo para securizar WordPress, en orden
Si mañana me llegara una web que no conozco, lo haría así, de más a menos importante:
- Actualizar el núcleo, los plugins y la plantilla, y quitar lo que no se usa.
- Copia externa y verificada, probada al menos una vez antes de necesitarla.
- PHP en una versión con soporte y con el último parche, mirando el número completo y, si no cuadra, preguntando por escrito al alojamiento.
- Usuarios y contraseñas: fuera los usuarios que ya no trabajan contigo, nada de «admin» y contraseñas largas y distintas.
- Un plugin de seguridad, como una capa más. Ayuda, pero va el último porque sin lo anterior no sirve de mucho.
Y una corrección, porque el título de aquel post antiguo de 2014 prometía algo que no se puede cumplir. Ninguna web queda segura de una vez por todas. Salen fallos nuevos, se instalan plugins nuevos, cambia el servidor. Lo que sí puedes hacer es reducir el riesgo y vigilar, y ese trabajo no se acaba.
Si prefieres que alguien haga estas comprobaciones cada mes, es lo que hacemos en nuestro mantenimiento WordPress con copias diarias verificadas, sin permanencia.
