WordPress publicó el 22 de septiembre de 2026 el aviso de seguridad GHSA-7hp8-65ch-5whp, en el que describe la CVE-2026-87902, una vulnerabilidad de traversal de rutas en la resolución de plantillas de páginas. El aviso asigna al fallo una puntuación CVSS v4 crítica de 9,2. La salvedad más importante es que se trata de una condición: un atacante de red no autenticado podría conseguir que get_page_template() incluya un archivo PHP local legible, seleccionado por el atacante y situado fuera de los directorios del tema activo, pero la ejecución remota de código exige condiciones adicionales de implementación y del tema. La mecánica y las listas de versiones que se presentan a continuación proceden de los propios hallazgos de WordPress; el material suministrado no contiene una reproducción independiente ni otro informe de seguridad.
El primer párrafo presenta el aviso de WordPress y su vulnerabilidad crítica, aunque condicional, de traversal de rutas.
La explotación comienza con el control de la resolución de plantillas, no con una cuenta de administrador. Según el aviso, el tema secundario o principal activo debe contener un directorio de nivel superior cuyo nombre empiece por page-, como page-templates. WordPress señala sus temas heredados Twenty Twelve y Twenty Fourteen como ejemplos, y también menciona Neve, Hestia y Sydney entre los temas de terceros afectados. Esos nombres ilustran la condición; el aviso no afirma que sean los únicos temas capaces de cumplirla. Por lo tanto, los propietarios de sitios deben inspeccionar la jerarquía del tema activo en lugar de depender únicamente de una lista de nombres de temas.
Un directorio coincidente no basta por sí solo. También debe existir un archivo PHP local seleccionado y la cuenta bajo la que se ejecuta PHP debe poder leerlo. El aviso identifica pearcmd.php como uno de los posibles objetivos y describe la transición establecida desde la ejecución de comandos PEAR cuando register_argc_argv está habilitado. Señala específicamente que la imagen Docker oficial de PHP se ve afectada en este sentido y que la configuración predeterminada de cPanel también lo está cuando utiliza una versión de PHP anterior a la 8.5. Estos ejemplos explican por qué el fallo puede ser crítico en algunos entornos de alojamiento, sin implicar que todas las instalaciones de WordPress expongan el archivo objetivo necesario o la configuración pertinente de PHP.
La distinción es importante desde el punto de vista operativo. Una solicitud no autenticada, sin privilegios y sin interacción de la víctima hace que el posible ataque sea alcanzable desde la red y relativamente sencillo una vez que están presentes sus prerrequisitos. Sin embargo, la métrica de requisitos de ataque del aviso registra que son necesarias condiciones previas de implementación. Por consiguiente, la evidencia respalda un modelo de riesgo condicional: la exposición depende de la interacción entre el código vulnerable de WordPress, una disposición elegible del tema, un objetivo PHP legible y la configuración correspondiente de PHP. No demuestra que todas las instalaciones que usan un tema mencionado permitan la ejecución remota de código, ni el aviso suministrado prueba que exista explotación activa en Internet.
WordPress indica que la versión 7.1.2 contiene la corrección y que esta se retroportó a las ramas anteriores compatibles hasta WordPress 4.7. Las versiones corregidas enumeradas son 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 y 4.7.37. Cada intervalo de versiones inmediatamente anterior mostrado en el aviso está marcado como afectado y se remonta hasta la 4.7.0.
Para los administradores, el primer paso práctico es comparar la versión instalada de WordPress con la versión corregida específica de su rama, en vez de comprobar solo si la instalación pertenece a una versión principal reciente. Una rama antigua pero totalmente corregida puede parecer desactualizada y, aun así, contener esta corrección; por el contrario, una versión principal actual inferior al punto corregido de su rama sigue siendo vulnerable. Después de actualizar, quienes administren sistemas de alto valor o expuestos a Internet deberían evaluar por separado si sus temas activos contienen un directorio page-* que cumpla los requisitos y si el entorno de ejecución de PHP expone un archivo legible utilizable en la cadena de inclusión descrita.
El aviso acredita a Robert Ressl la divulgación responsable y clasifica la debilidad como CWE-98, que abarca el control inadecuado del nombre de un archivo utilizado en una operación PHP include o require. Esa clasificación es coherente con el fallo comunicado durante la selección del archivo de plantilla. No obstante, no significa que un atacante pueda incluir una URL remota arbitraria ni eludir los permisos de lectura del sistema operativo. La ruta documentada requiere un objetivo PHP local que la cuenta del servidor web pueda leer, seguido de las condiciones adicionales necesarias para convertir la inclusión en ejecución de código.
La conclusión central para el lector es, por tanto, más específica de lo que sugiere por sí sola la gravedad del titular. La CVE-2026-87902 merece una corrección rápida porque, una vez que el entorno es adecuado, no se requieren autenticación, interacción del usuario ni pasos de ataque complejos. Al mismo tiempo, la divulgación disponible no permite considerar que todos los sitios de WordPress estén expuestos por igual. Actualizar a la versión corregida adecuada elimina la ruta de código vulnerable; evaluar la estructura de los temas y las condiciones de implementación de PHP ayuda a los operadores a comprender el riesgo residual y a priorizar los sistemas en los que podría haber existido la cadena completa de explotación.