Una investigación de Censys ha detectado que solo el 14 % de una muestra de 316.500 instalaciones de WordPress utilizaba la versión más reciente cuando se realizó el análisis. El dato equivale a un 86 % de webs retrasadas, pero necesita contexto: la muestra solo incluye sitios que hacían visibles las versiones de WordPress y PHP, no el conjunto de instalaciones existentes en internet.
Las claves de la seguridad de WordPress en 20 segundos
El estudio ofrece una fotografía preocupante de cómo se mantiene una parte de la web. Censys identificó más de 59 millones de entidades públicas relacionadas con WordPress, distribuidas entre alrededor de un millón de direcciones IP. Sin embargo, la compañía solo pudo comprobar simultáneamente las versiones del gestor y de PHP en algo más de 316.500 casos, aproximadamente el 0,5 % de esa población visible.
Por eso no sería riguroso afirmar que el 86 % de todos los WordPress del mundo está desactualizado. Sí puede concluirse que el retraso es enorme entre los sitios cuya configuración permite identificar las versiones utilizadas. Ocultar ese dato tampoco protege una web vulnerable: dificulta una comprobación superficial, pero no impide que un atacante pruebe automáticamente fallos conocidos.
Cuando Censys recopiló los datos, unos 44.000 sitios de la muestra utilizaban WordPress 7.0, entonces la última versión. Eso representaba el 14 %. Si se añadían las instalaciones de la rama 6.9, el porcentaje alcanzaba aproximadamente el 31 %.
Desde la publicación del informe, el proyecto ha lanzado nuevas revisiones. La versión vigente es WordPress 7.0.2, publicada el 17/07/2026. WordPress.org indica que únicamente la última rama principal recibe soporte oficial completo, aunque ocasionalmente se distribuyen correcciones para versiones anteriores cuando aparece una vulnerabilidad grave.
La actualización 7.0.2 no es una revisión menor prescindible. Corrige un problema crítico y otro de severidad alta: una inyección SQL facilitada y una confusión en las rutas por lotes de la interfaz REST que podía terminar en ejecución remota de código. Debido a la gravedad, WordPress activó actualizaciones forzadas en los sitios compatibles con su sistema automático. También publicó las versiones 6.9.5 y 6.8.6 con las correcciones correspondientes para las ramas afectadas.
Esto introduce un matiz importante. El 14 % de Censys no indica cuántos sitios están hoy en WordPress 7.0.2. El estudio se publicó el 01/07/2026 y la nueva actualización de seguridad llegó más de dos semanas después. La fotografía ha envejecido, pero el problema que muestra sigue vigente: millones de administradores tardan demasiado en aplicar revisiones.
| Capa de la web | Situación observada | Riesgo principal |
|---|---|---|
| WordPress Core | Solo el 14 % estaba en la última versión medida | Fallos conocidos sin corregir |
| PHP | Más del 70 % utilizaba versiones desactualizadas | Vulnerabilidades sin soporte oficial |
| Plugins | Menos del 22 % de los Yoast visibles tenía la última versión | Entradas adicionales al sistema |
| Configuración | XML-RPC, SSH y otros servicios expuestos | Ataques automatizados y fuerza bruta |
| Copias de seguridad | Censys no las puede medir desde internet | Recuperación difícil tras un incidente |
Una instalación puede tener el núcleo actualizado y seguir expuesta por la versión de PHP, un plugin abandonado, un tema antiguo o una mala configuración del servidor.
Censys encontró que más del 70 % de los sitios de la muestra utilizaba una versión desactualizada de PHP. La más frecuente era PHP 7.4, presente en más del 20 % de los casos pese a haber llegado al final de su vida útil en noviembre de 2022.
PHP mantiene actualmente las ramas 8.2, 8.3, 8.4 y 8.5. Las dos primeras reciben únicamente correcciones de seguridad, mientras 8.4 y 8.5 continúan con soporte activo. PHP 8.2 dejará de recibir incluso parches críticos al terminar 2026.
Actualizar PHP puede resultar más delicado que instalar una revisión de WordPress. Un plugin antiguo puede utilizar funciones retiradas o comportarse de manera diferente. Esa posibilidad explica parte del retraso, pero no convierte en segura una versión sin soporte. Solo significa que la migración debe probarse antes en una copia de la web.
Los complementos añaden otra capa. Censys detectó aproximadamente 7,5 millones de sitios con algún plugin identificable. Más de cinco millones mostraban rastros de Yoast SEO, pero menos del 22 % utilizaba la versión más reciente disponible durante el análisis.
El dato no implica que todas las versiones anteriores de Yoast contengan una vulnerabilidad explotable. Censys eligió este complemento por su gran visibilidad para ilustrar la escasa frecuencia con la que se aplican actualizaciones. Un plugin puede estar desactualizado y no ser vulnerable, pero cada retraso aumenta el periodo durante el que un fallo ya corregido puede seguir abierto.
Los atacantes aprovechan precisamente esa escala. No necesitan revisar manualmente cada web. Pueden rastrear millones de dominios, identificar rutas conocidas y probar vulnerabilidades, contraseñas o configuraciones débiles de forma automatizada.
Censys relaciona este escenario con la campaña de desfiguración denominada MR.GREEN. En junio había más de 900 páginas mostrando el mensaje “Hacked By MR.GREEN”. La compañía no ha identificado el método exacto de entrada, por lo que no puede atribuir todos los casos a una vulnerabilidad concreta. Sí observó entre las víctimas software antiguo, el archivo xmlrpc.php expuesto, instalaciones incompletas y accesos SSH con configuraciones débiles.
Los sensores de GreyNoise también registraron 70 direcciones IP que habían buscado endpoints xmlrpc.php durante los 90 días anteriores. XML-RPC tiene usos legítimos, pero puede emplearse para probar contraseñas, enumerar componentes o abusar de la función de pingback cuando permanece disponible sin necesidad.
La lección no es que cualquier WordPress con XML-RPC vaya a ser atacado con éxito. El riesgo aparece cuando se acumulan varias debilidades: PHP sin soporte, plugins antiguos, contraseñas reutilizadas, permisos excesivos, servicios de administración abiertos y ausencia de vigilancia.
El miedo a que una actualización deje la web fuera de servicio es comprensible. La respuesta no debería ser aplazarla indefinidamente, sino disponer de un proceso que permita detectar errores y volver atrás.
El primer paso es realizar una copia completa de la base de datos y de los archivos. La copia debe estar fuera del mismo servidor y conviene comprobar que realmente puede restaurarse. WordPress recomienda hacerla siempre antes de una actualización, ya que un retorno fiable resulta muy difícil sin los datos y archivos anteriores.
Después debe crearse un entorno de pruebas o staging que reproduzca, en la medida de lo posible, la versión de PHP, el tema, los plugins y la configuración de producción. Allí se pueden aplicar los cambios y comprobar formularios, compras, accesos, cachés, correos, tareas programadas y panel de administración.
El orden también importa:
Tampoco conviene convertir las actualizaciones automáticas en una discusión de todo o nada. Las revisiones de seguridad del núcleo deben instalarse rápidamente y las automatizaciones pueden reducir el tiempo de exposición. Los cambios mayores y los plugins que afectan a funciones críticas necesitan pruebas previas.
Una web que no puede actualizarse sin romperse tiene además un problema técnico anterior al parche. Puede depender de código abandonado, modificaciones realizadas directamente sobre el núcleo o un tema que no se mantiene desde hace años. En esos casos, la solución no consiste en permanecer para siempre en PHP 7.4, sino en planificar una modernización por etapas.
El informe de Censys no demuestra que cada instalación antigua esté comprometida. Muestra algo igualmente incómodo: existen suficientes objetivos desatendidos como para que resulte rentable buscarlos de forma automática. Los atacantes no necesitan técnicas sofisticadas cuando pueden encontrar una web que lleva años sin recibir mantenimiento.
¿Está realmente desactualizado el 86 % de todos los WordPress?
No puede afirmarse eso. El porcentaje corresponde a unas 316.500 instalaciones que exponían las versiones de WordPress y PHP, una pequeña parte de los más de 59 millones de sitios visibles detectados por Censys.
¿Cuál es la versión actual de WordPress?
La última versión disponible es WordPress 7.0.2, publicada el 17/07/2026. Corrige dos vulnerabilidades graves y WordPress recomienda actualizar inmediatamente.
¿Es peligroso utilizar un PHP antiguo aunque WordPress esté actualizado?
Sí. Una rama que ha llegado al final de su soporte puede conservar vulnerabilidades sin parche oficial. Además, plugins y temas se ejecutan sobre PHP y dependen de la seguridad de esa capa.
¿Deben activarse todas las actualizaciones automáticas?
No existe una respuesta única. Las revisiones críticas deberían aplicarse cuanto antes, mientras los cambios mayores y los plugins esenciales conviene probarlos previamente en un entorno separado.
vía: cybernews
