El equipo de seguridad de WordPress ha lanzado la versión 7.1.2, una actualización exclusivamente de seguridad que corrige una vulnerabilidad crítica en el núcleo del CMS que podría permitir a cualquier visitante no autenticado ejecutar código de forma remota en algunos sitios web. Lo más llamativo del caso, según los datos facilitados por Patchstack, es que los atacantes empezaron a sondear la brecha menos de cinco horas después de publicarse el parche.
Qué es lo que falla y por qué es tan grave
Según la información del aviso oficial de seguridad publicado en GitHub, la vulnerabilidad afecta a la forma en que WordPress determina qué archivo de plantilla debe cargar al mostrar una página. Un visitante anónimo puede engañar a ese proceso para que cargue un archivo PHP desde fuera de las carpetas del tema activo, lo que se conoce como inclusión de archivos locales (LFI).
De acuerdo con el análisis de Patchstack, WordPress ya contaba con una comprobación para evitar este tipo de manipulación de rutas en otra parte del mismo código, pero no estaba aplicada al valor tomado directamente de la petición del visitante. El fallo ha recibido una puntuación de 9,2 sobre 10 en la escala CVSS 4.0, lo que lo sitúa en la categoría de crítico.
Dos condiciones tienen que darse a la vez para que la vulnerabilidad desemboque en ejecución remota de código. Según los datos del aviso oficial, el tema activo necesita tener una carpeta de nivel superior cuyo nombre empiece por page- (los temas predeterminados Twenty Twelve y Twenty Fourteen, y los temas Neve, Hestia y Sydney cumplen ese requisito), y el servidor debe tener accesible un archivo PHP que sea útil para un atacante cuando se carga.
La ruta más conocida hacia la ejecución de código pasa por un archivo que se distribuye con PEAR, el gestor de paquetes heredado de PHP, que se vuelve peligroso cuando la configuración register_argc_argv de PHP está activada. De acuerdo con la fuente, la imagen oficial de PHP para Docker y las configuraciones por defecto de cPanel que usan PHP por debajo de la versión 8.5 se ven afectadas.
Cómo actúan los atacantes después del parche
Patchstack registró las primeras sondas a las 17:44 UTC del martes 23 de septiembre, el mismo día en que se publicó el parche. Según Dave Jong, responsable de investigación de seguridad en Patchstack, los payloads detectados coincidían exactamente con la codificación que el parche corrige, lo que indica que quienes los construyeron trabajaron a partir del propio diff de la actualización en lugar de descubrir el fallo por su cuenta.
Jong describió el tráfico inicial como reconocimiento: los atacantes apuntaban el fallo hacia archivos inofensivos del núcleo de WordPress para comprobar si la inclusión funcionaba, construyendo así una lista de sitios vulnerables. Según sus palabras, se trata de una técnica barata y fiable para identificar objetivos. El paso realmente peligroso —apuntar el mismo mecanismo hacia archivos como pearcmd.php en servidores con la configuración vulnerable— no había aparecido aún en los datos de Patchstack en el momento de la publicación.
Quién descubrió el fallo y cuándo
El ingeniero de seguridad Robert Ressl, con sede en Zúrich, fue quien detectó y reportó la vulnerabilidad a través del programa HackerOne de WordPress el 20 de julio de 2026, dos días después de que se publicara la actualización de emergencia WordPress 7.0.2. En un post en su blog publicado junto al parche, Ressl explicó que su reporte fue clasificado de forma diferente inicialmente antes de ser aceptado como válido.
Según explicó el propio Ressl, tuvo noticias de que el parche llegaría el 15 de septiembre, aunque la publicación definitiva se retrasó hasta finales de ese mes. La espera de dos meses coincidió, de acuerdo con la fuente, con un periodo en el que la bandeja de entrada de HackerOne del equipo de seguridad de WordPress se vio inundada por informes generados con IA.
Qué cambia con la corrección y cómo protege más allá del fallo inmediato
La actualización no se limita a tapar el agujero concreto. Según el análisis de Patchstack, el parche añade la comprobación que faltaba y va un paso más allá con una regla más amplia que obliga a que todos los archivos de plantilla que carga WordPress estén dentro de una carpeta de tema aprobada.
Para los investigadores de Patchstack, ese paso adicional demuestra que el equipo de seguridad de WordPress ha enfocado la solución como si la resolución de plantillas fuera una clase de problema en sí misma, no un fallo puntual. Es una señal de que se ha reforzado el modelo de seguridad en un área más amplia del código.
A quién afecta y qué hacer ahora mismo
El parche ha sido retroportado a todas las ramas de WordPress desde la versión 4.7, por lo que prácticamente cualquier instalación activa puede actualizarse. John Blackbourn, representante del equipo de seguridad de WordPress con el respaldo de Human Made, fue quien lideró el lanzamiento y publicó el anuncio oficial en WordPress.org.
Los sitios con las actualizaciones automáticas en segundo plano activadas ya deberían tener el parche instalado. Para el resto, el post de publicación oficial recomienda actualizar de forma inmediata. A continuación, los factores de riesgo clave que conviene revisar:
- Temas activos con carpetas de nivel superior cuyo nombre empiece por
page-(Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney, entre otros). - Servidores con PHP usando la imagen Docker oficial o configuraciones cPanel con PHP por debajo de 8.5.
- Configuración de PHP con
register_argc_argvactivada. - Presencia de
pearcmd.phpaccesible en el servidor.
Aunque la superficie de ataque es más reducida que la de la vulnerabilidad que corrigió WordPress 7.0.2 en julio —que funcionaba en una instalación limpia sin plugins—, según los datos facilitados por Patchstack, la velocidad con la que los atacantes han comenzado a sondear hace que actualizar sin demora sea la única opción razonable.
El contexto: una racha de parches críticos en WordPress
WordPress 7.1.2 llega menos de una semana después de que WordPress 7.1.1 publicara once correcciones de seguridad. Según la fuente, desde julio todos los lanzamientos de seguridad del núcleo habían incluido créditos a empresas de IA o a descubrimientos asistidos por IA, desde la versión 7.0.2 hasta la 7.1.1. Sin embargo, ni el post de publicación de 7.1.2 ni el aviso oficial mencionan a ninguna compañía de IA.
El fallo descubierto por Ressl es el segundo RCE en el núcleo de WordPress en apenas dos meses, lo que refleja un período de intensa actividad en el ámbito de la seguridad del CMS más usado del mundo. De acuerdo con los datos disponibles, el volumen de reportes en el programa HackerOne de WordPress se ha disparado de forma notable en los últimos meses, en parte por la proliferación de herramientas de IA capaces de analizar código en busca de vulnerabilidades.