Spoiler: no, esta vez no estamos hablando de una única versión de WordPress. En las últimas semanas se han encadenado varios parches de seguridad del Core y hay una pregunta más interesante que “¿qué número instalo?”: ¿por qué están apareciendo tantos problemas ahora?
Este artículo está actualizado a 24 de septiembre de 2026. La foto corta es sencilla: entre julio y septiembre WordPress publicó las versiones 7.0.2, 7.0.3, 7.0.4, 7.1.1 y 7.1.2. Los comunicados suman 27 correcciones o elementos de seguridad, aunque eso no significa que haya 27 vulnerabilidades únicas ni 27 CVEs: algunas correcciones no tienen identificador propio y una misma necesidad de seguridad puede recibir correcciones retroportadas en varias ramas.
La lista rápida: qué ha pasado
- 17 de julio, WordPress 7.0.2: corrige una cadena de inyección SQL y confusión en la REST API que, encadenada, podía terminar en ejecución remota de código sin autenticación. Es el caso wp2shell.
- 6 de agosto, WordPress 7.0.3: llega un lote de doce correcciones: XSS, autorización en Multisite, enumeración de slugs, SSRF y otros problemas de autorización y exposición de datos.
- 12 de agosto, WordPress 7.0.4: corrige una RCE de nivel Author o superior al procesar una carga PostScript con Imagick y Ghostscript.
- 17 de septiembre, WordPress 7.1.1: trae once correcciones de seguridad, incluyendo XSS, autorización, REST, XML-RPC, Multisite y una vía de instalación forzada de themes.
- 22 de septiembre, WordPress 7.1.2: corrige CVE-2026-87902, una inclusión local de PHP sin autenticación que puede llevar a RCE si se cumplen ciertas condiciones del theme y del servidor.
No todas las vulnerabilidades son iguales
La palabra “crítica” es engañosa si la leemos sin contexto. Un fallo sin autenticación que puede abrir una ruta de ejecución no es lo mismo que un XSS que necesita que una persona haga clic. También hay diferencias entre un defecto que ya se está explotando activamente y uno del que solo existe una prueba de concepto.
Por eso conviene separar tres preguntas: qué parte de WordPress está afectada, qué condiciones necesita el atacante y qué evidencia hay de explotación real. No porque queramos echarle la culpa a nadie, sino para no convertir una alerta técnica en una película de terror.
Julio: la cadena wp2shell
WordPress 7.0.2 corrige dos problemas que, por separado, no son la misma historia. Uno está relacionado con una inyección SQL en WP_Query y el otro con la confusión de rutas del endpoint batch de la REST API. La combinación podía permitir crear una cuenta administrativa y cargar código sin que el atacante tuviera que iniciar sesión.
Las identificaciones son CVE-2026-60137 / GHSA-fpp7-x2x2-2mjf para la inyección SQL y CVE-2026-63030 / GHSA-ff9f-jf42-662q para la cadena que conduce a RCE. CISA añadió ambos problemas a su catálogo de vulnerabilidades explotadas y SANS observó solicitudes y un exploit que escribía una webshell. Eso demuestra actividad de explotación; no demuestra que todos los sitios que usaban una versión antigua estuvieran comprometidos.
Agosto: muchos problemas, no solo una RCE
El lote 7.0.3 es un buen recordatorio de que la seguridad de WordPress no vive solo en la pantalla de login. Incluye una vulnerabilidad XSS reflejada en el login (CVE-2026-64638 / GHSA-52p2-r8wf-jcrf), XSS almacenadas en contenidos y ajustes, una escalada de privilegios en Multisite, una SSRF en la validación de URLs, enumeración de slugs y divulgaaciones de información.
El 12 de agosto, 7.0.4 corrige CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w: una ejecución remota de código de nivel Author o superior al procesar un archivo PostScript malicioso. No es preautenticación ni afecta a todas las instalaciones: necesita una cuenta con permisos de subida y una pila concreta con Imagick y Ghostscript.
Septiembre: autorización, HTML, archivos y plantillas
WordPress 7.1.1 corrige once avisos de seguridad. Entre ellos hay XSS almacenada en comentarios y datos de cabecera, problemas de autorización para roles bajos, una ruta de lectura de archivos HTML en el controlador de plantillas REST, problemas de XML-RPC y una primitiva de instalación forzada de themes. Esta última se ha relacionado con Click2Shell, pero hay que ser precisos: la demostración de RCE también usa un fallo separado de un theme/plugin. No es un único CVE de Core.
El 22 de septiembre llegó 7.1.2 con CVE-2026-87902 / GHSA-7hp8-65ch-5whp. El fallo está en la resolución de plantillas de página de Core: un atacante sin autenticación puede intentar incluir un archivo PHP local fuera de la ruta del theme. Para convertir la inclusión local en ejecución de código deben coincidir más condiciones, como una estructura concreta del theme y un archivo local accesible al servidor.
Patchstack observó solicitudes coincidentes el mismo día del lanzamiento e intentos de escritura en ubicaciones temporales. La lectura prudente es “se observaron intentos activos”; no “se han comprometido miles de webs”. La actualización corrige el camino conocido, pero no limpia por sí sola un archivo que un atacante hubiera dejado antes.
Mi opinión: más ojos, no una campaña coordinada
Esto es una opinión informada, no un hecho confirmado. Mi lectura es que estamos viendo una combinación de tres cosas:
- Más capacidad de descubrimiento y reporte. El propio proyecto ha reconocido un aumento sustancial de avisos y ha hablado de herramientas de análisis asistidas por IA. Eso puede descubrir más rápido un fallo que antes habría esperado una revisión manual. No significa que una máquina haya inventado todos los problemas ni que todos los investigadores usen IA.
- Una cola de ataque muy rentable. Los investigadores insisten en fronteras donde una petición no confiable se convierte en una acción privilegiada: REST, SQL, autorización, comentarios, HTML, subidas, SSRF y resolución de archivos. Son superficies con mucho retorno y no una prueba de que una zona concreta sea estadísticamente más insegura que las demás.
- Un ciclo de divulgación cada vez más corto. En cuanto sale un parche aparecen escáneres, pruebas de concepto y intentos de explotación. En julio se confirmó explotación de wp2shell; en septiembre se observaron intentos contra 87902. Eso explica por qué la actividad posterior a un aviso crece tan rápido, aunque no demuestra que todos los incidentes pertenezcan a una misma campaña.
No veo pruebas suficientes para decir que existe una operación coordinada contra WordPress, una brecha general del proyecto o una “oleada” con un único actor. Lo que sí vemos es un ecosistema con más herramientas, más ojos y menos tiempo entre el descubrimiento y el escaneo. Los retroportados a ramas antiguas también hacen que una misma oleada parezca aún más grande: un problema puede aparecer en varias versiones reparadas a la vez.
¿Qué hago si tengo una web WordPress?
- Actualiza al último parche de tu rama. En la rama 7.1, la referencia de este momento es 7.1.2; en la 7.0, 7.0.6. Un número inferior en otra rama no significa automáticamente que estés más protegido.
- Haz una copia antes de actualizar. Archivos y base de datos, y una copia fuera del servidor.
- Actualiza también plugins y themes. El caso Click2Shell es un recordatorio de que una cadena puede empezar en Core y terminar en un componente del ecosistema.
- Revisa administradores y accesos. Busca usuarios que no reconozcas, cambios de contraseña, solicitudes extrañas a `/wp-json/batch/v1` y archivos PHP inesperados.
- Revisa los temporales del servidor. Si ves PHP en `/tmp` o `/var/tmp` y no debería estar ahí, guarda logs y trata el servidor como comprometido hasta demostrar lo contrario.
- Reduce privilegios. No abras el registro si no lo necesitas, limita roles, mantén MFA y desactiva XML-RPC si ningún servicio lo utiliza.
Y no te asustes si llevas semanas sin actualizar: no significa que tu web esté hackeada. Significa que ahora toca cerrar la puerta, revisar lo que ha podido pasar y ponerse al día sin improvisar. La actualización es el primer paso; la investigación posterior es otra tarea.
La conclusión, sin tanto ruido
La noticia no es que WordPress se haya roto ni que todos los blogs estén en peligro. La noticia es que la diferencia entre descubrir un fallo, publicar su parche y empezar a escanear la web se está acortando. En ese escenario, la mejor estrategia no es entrar en pánico ni mantener el core congelado: es actualizar con regularidad, comprobar que el despliegue ocurrió y mantener el resto de la web —plugins, themes, cuentas y servidor— bajo control.
Y sí, este blog ya está funcionando con WordPress 7.1.2. La lección sigue siendo la de siempre: mantenimiento aburrido, copias y actualizaciones. La parte divertida es que, por una vez, WordPress nos está dando material para hablar de seguridad durante varios artículos… o para uno muy largo. Ambas cosas.
Fuentes y avisos
- WordPress 7.0.2 Release: cadena wp2shell y sus ramas corregidas.
- WordPress 7.0.3 Release y WordPress 7.0.4 Release: lotes de agosto.
- WordPress 7.1.1 Release y WordPress 7.1.2 Release: avisos de septiembre.
- GHSA-ff9f-jf42-662q, GHSA-8vr3-7mxf-gx8w y GHSA-7hp8-65ch-5whp: fichas técnicas de los casos destacados.
- CISA KEV y Patchstack: indications de explotación y escaneo.
