Solo el 14 % de las instalaciones de WordPress analizadas por Censys utilizaba la versión más reciente del gestor de contenidos cuando se recogieron los datos. La cifra dibuja una superficie de ataque considerable, aunque no representa a todo el ecosistema: el estudio se limita a unas 316.500 webs que mostraban públicamente las versiones de WordPress y PHP utilizadas.
Las claves de la brecha de seguridad de WordPress en 20 segundos
- El 86 % de la muestra no ejecutaba el WordPress más reciente.
- Más del 70 % utilizaba versiones antiguas de PHP.
- La campaña MR.GREEN había desfigurado más de 900 webs.
- WordPress 7.0.2 corrige dos vulnerabilidades graves y debe instalarse de inmediato.
Censys identificó en junio de 2026 más de 59 millones de entidades web relacionadas con WordPress, desplegadas sobre cerca de un millón de direcciones IP. La mayoría no exponía información suficiente para determinar su versión, por lo que el análisis detallado se concentró en alrededor del 0,5 % de esa población visible. No puede afirmarse que el 86 % de todos los WordPress del mundo esté desactualizado, pero sí que existe una acumulación de deuda técnica fácil de localizar desde internet.
El problema tampoco se limita al núcleo del gestor. PHP, los plugins, los temas, los accesos remotos y la configuración del servidor forman parte de la misma superficie. Un atacante automatizado no necesita encontrar una vulnerabilidad inédita si puede localizar miles de sistemas con fallos conocidos, credenciales débiles o servicios innecesariamente expuestos.
WordPress actualizado sobre un PHP abandonado
Dentro de la muestra de Censys, unas 44.000 instalaciones ejecutaban WordPress 7.0, la versión más reciente en el momento del estudio. Otras mantenían versiones anteriores del núcleo, mientras la situación de PHP resultaba todavía más preocupante: solo unas 94.000 webs, alrededor del 30 %, utilizaban una rama que seguía recibiendo parches.
PHP 7.4 era la versión más observada y aparecía en más del 20 % de los sitios analizados, pese a haber terminado su soporte en noviembre de 2022. En esas instalaciones, una vulnerabilidad nueva no recibirá una corrección oficial del proyecto PHP.
Las ramas de PHP que continúan soportadas son 8.2, 8.3, 8.4 y 8.5. Las dos primeras reciben únicamente correcciones de seguridad, mientras 8.4 y 8.5 mantienen soporte activo. PHP 8.2 llegará al final de su ciclo el 31/12/2026.
| Capa | Hallazgo de Censys | Riesgo |
|---|---|---|
| WordPress Core | Solo el 14 % estaba en la última versión medida | Explotación de vulnerabilidades ya corregidas |
| PHP | Más del 70 % utilizaba versiones desactualizadas | Fallos sin parche y menor compatibilidad futura |
| Plugins | Menos del 22 % de los Yoast visibles estaba al día | Cada extensión añade una posible vía de entrada |
| XML-RPC | Escaneos automatizados continuos | Fuerza bruta, enumeración y abuso de funciones |
| SSH | Puertos abiertos y autenticación por contraseña | Acceso remoto y movimiento posterior |
La presencia de una versión antigua no demuestra por sí sola que una web sea explotable. También puede haber mitigaciones externas, parches aplicados por el proveedor de alojamiento o cabeceras de versión incorrectas. Sin embargo, mantener software fuera de soporte elimina una de las defensas básicas: la posibilidad de recibir una corrección cuando aparece un fallo.
Ocultar la versión tampoco resuelve el problema. Puede reducir algunos sondeos simples, pero los atacantes pueden identificar tecnologías por sus rutas, archivos estáticos, respuestas HTTP, comportamiento o componentes instalados.
Dos vulnerabilidades graves obligan a actualizar ahora
La fotografía de Censys ya ha quedado parcialmente superada por una nueva actualización de seguridad. WordPress 7.0.2 se publicó el 17/07/2026 para corregir un problema crítico y otro de gravedad alta. El equipo de WordPress activó actualizaciones automáticas forzadas en las instalaciones compatibles debido a la severidad de los fallos.
Las vulnerabilidades corregidas son:
| Vulnerabilidad | Descripción | Versiones corregidas |
|---|---|---|
| CVE-2026-60137 | Problema de inyección SQL facilitada | 7.0.2, 6.9.5 y 6.8.6 |
| CVE-2026-63030 | Confusión en rutas por lotes de la API REST e inyección SQL con posible ejecución remota de código | 7.0.2 y 6.9.5 |
WordPress 6.9 estaba afectado por los dos problemas. La rama 6.8 solo estaba expuesta al primero y las versiones anteriores a 6.8 no estaban afectadas, según el aviso oficial. Esto no convierte en seguras a todas las ramas antiguas: WordPress solo considera oficialmente soportada la última versión principal y los parches para ediciones anteriores se publican como cortesía cuando la gravedad lo aconseja.
Para los equipos de seguridad, la prioridad inmediata es verificar que las actualizaciones automáticas se hayan completado. La presencia de WordPress 7.0 o 7.0.1 ya no basta. La versión segura de la rama actual es 7.0.2.
Los atacantes no necesitan una vulnerabilidad de día cero
Censys también analizó la campaña de desfiguración MR.GREEN. Más de 900 webs mostraban en junio el mensaje “Hacked By MR.GREEN”, casi todas basadas en gestores de contenidos y con WordPress como plataforma más habitual.
Los investigadores no han podido determinar un vector de acceso único. Las víctimas compartían, sin embargo, una combinación reconocible: software antiguo, archivos de instalación expuestos, xmlrpc.php accesible y servicios SSH abiertos sin restricciones de dirección IP y con autenticación mediante contraseña.
GreyNoise había observado 70 direcciones IP buscando endpoints xmlrpc.php durante los 90 días anteriores. XML-RPC mantiene usos legítimos en integraciones y publicación remota, pero también permite automatizar intentos de autenticación, enumerar componentes y abusar de determinadas funciones cuando no se encuentra correctamente protegido.
La campaña ilustra cómo se producen muchos ataques contra WordPress. El adversario no selecciona inicialmente una empresa concreta. Escanea internet, clasifica objetivos por tecnología y versión, prueba técnicas conocidas y conserva aquellos en los que obtiene acceso.
Una web desfigurada puede parecer un incidente menor, pero el mismo punto de entrada puede utilizarse para insertar redirecciones, distribuir malware, crear cuentas administrativas, robar bases de datos, enviar spam o alojar páginas de phishing. La ausencia de una segunda fase visible no demuestra que el servidor permanezca limpio.
Cómo reducir la superficie sin romper producción
Desactivar todas las actualizaciones por miedo a una incompatibilidad no es una estrategia de seguridad. WordPress activa por defecto las revisiones menores y de seguridad, y su documentación desaconseja expresamente bloquearlas. Los cambios principales, los saltos de PHP y las actualizaciones de plugins críticos sí deberían probarse antes en un entorno separado.
Un procedimiento razonable debe incluir:
- Inventario completo. Registrar versiones de WordPress, PHP, base de datos, plugins, temas, servidor web y sistema operativo.
- Copia restaurable. Mantener archivos y base de datos fuera del servidor principal y realizar pruebas periódicas de recuperación.
- Entorno de pruebas. Reproducir la instalación en staging antes de cambiar PHP, el tema o componentes esenciales para ventas, formularios o autenticación.
- Priorización por riesgo. Aplicar inmediatamente las actualizaciones de seguridad y programar después los cambios funcionales menos urgentes.
- Reducción de plugins. Eliminar extensiones y temas que no se utilicen. Un plugin desactivado puede seguir dejando archivos vulnerables en el servidor.
- Control de accesos. Implantar contraseñas únicas, autenticación multifactor y el menor número posible de cuentas administradoras.
- Endurecimiento del servidor. Restringir SSH por red o VPN, utilizar claves y deshabilitar la autenticación por contraseña siempre que resulte posible.
- Revisión de XML-RPC. Desactivarlo o limitarlo cuando ninguna aplicación dependa de él.
- Supervisión posterior. Revisar cambios en archivos, cuentas creadas, tareas programadas, errores PHP, registros de acceso y tráfico saliente.
- Plan de retirada. Sustituir plugins y temas abandonados antes de que bloqueen una actualización futura de PHP o WordPress.
El informe de Censys no revela una nueva técnica sofisticada. Expone un problema más incómodo: una gran cantidad de servidores continúa ofreciendo a los atacantes vulnerabilidades conocidas y configuraciones previsibles. Cuando el escaneo, la selección del objetivo y parte de la explotación pueden automatizarse, cada mes de retraso aumenta el periodo disponible para encontrar la web antes que su administrador.
Preguntas frecuentes
¿Está desactualizado el 86 % de todos los sitios WordPress?
No puede asegurarse. El porcentaje corresponde a unas 316.500 instalaciones que exponían las versiones de WordPress y PHP, no a los más de 59 millones de activos visibles detectados por Censys.
¿Qué versión de WordPress debe instalarse ahora?
La versión actual es WordPress 7.0.2. Corrige dos problemas de seguridad graves y debe aplicarse inmediatamente en las instalaciones afectadas.
¿Actualizar WordPress protege también frente a plugins vulnerables?
No. El núcleo, los plugins, los temas, PHP y el servidor tienen ciclos de actualización diferentes. Cada componente debe mantenerse y supervisarse por separado.
¿Es suficiente instalar un firewall de aplicaciones web?
No. Un WAF puede bloquear parte de los intentos de explotación, pero no sustituye los parches, la reducción de permisos, el control de accesos ni la eliminación de componentes abandonados.
