WordPress 7.1.2 corrige una vulnerabilidad crítica sin autenticación con RCE condicional; ya se observan sondeos
Fecha efectiva / observada:
Qué ha cambiado
WordPress 7.1.2 ya está disponible como actualización de seguridad urgente. Corrige una vulnerabilidad crítica en la resolución de plantillas de página que puede permitir a un atacante no autenticado incluir un archivo PHP local legible fuera de los directorios del tema y, si además se cumplen determinadas condiciones del tema y del servidor, llegar a ejecución remota de código (RCE). WordPress recomienda actualizar los sitios inmediatamente. QUÉ HA CAMBIADO WordPress publicó la versión 7.1.2 el 22 de septiembre de 2026. La versión contiene una única corrección de seguridad, pero su severidad oficial es crítica. El aviso de seguridad de WordPress/GitHub la identifica como: - path traversal sin autenticación; - inclusión de archivos PHP locales; - RCE condicional; - CVE-2026-87902; - CVSS 4.0: 9,2/10. No necesita una cuenta previa ni interacción de un usuario para iniciar el ataque. QUÉ VERSIONES ESTÁN AFECTADAS El advisory oficial cubre WordPress desde la rama 4.7 hasta 7.1.1. La versión corregida de la rama actual es: - WordPress 7.1.2. WordPress también ha publicado backports para las ramas antiguas afectadas, entre ellas: - 7.0.6; - 6.9.9; - 6.8.10; - 6.7.9; - 6.6.9; - y correcciones sucesivas hasta 4.7.37. WordPress 4.6 y anteriores ya no reciben esta actualización de seguridad. Esto significa que incluso un sitio que hubiera actualizado hace pocos días a WordPress 7.1.1 necesita volver a actualizar. ID88 recomendaba pasar a 7.1.1 por las 11 vulnerabilidades corregidas el 17 de septiembre. ID90 sustituye ahora esa recomendación operativa: 7.1.1 ya no es la versión que debe considerarse actual para la rama 7.1. CÓMO FUNCIONA EL FALLO La vulnerabilidad está en la forma en que WordPress resuelve qué archivo de plantilla debe utilizar para una página. Un atacante no autenticado puede manipular esa resolución para intentar salir de los directorios normales del tema y hacer que WordPress incluya un archivo PHP local legible. El problema afecta a `get_page_template()` y a la construcción de candidatos derivados de `pagename`. La corrección de WordPress añade validaciones para impedir recorridos de ruta y refuerza la comprobación de que la plantilla finalmente resuelta permanezca dentro de ubicaciones permitidas. INCLUSIÓN LOCAL NO SIGNIFICA RCE AUTOMÁTICA Es importante separar dos cosas. INCLUSIÓN DE ARCHIVO LOCAL → WordPress puede llegar a cargar un PHP local fuera de los directorios esperados. RCE → exige además que el entorno disponga de un archivo PHP local adecuado y que se cumplan otras condiciones del servidor. Por tanto: “vulnerabilidad crítica con RCE condicional” es correcto. “cualquier WordPress 7.1.1 puede ser tomado automáticamente” no lo es. QUÉ PRECONDICIONES DOCUMENTA WORDPRESS El advisory oficial explica que el peor escenario requiere, entre otros factores: - que el tema padre o hijo activo tenga un directorio de nivel superior cuyo nombre empiece por `page-`, por ejemplo `page-templates`; - que exista en el servidor un archivo PHP local adecuado, legible por la cuenta del servidor web. WordPress cita como ejemplos de temas con ese tipo de directorio: - Twenty Twelve; - Twenty Fourteen; - Neve; - Hestia; - Sydney. Eso no significa que todos los sitios con esos temas sean automáticamente explotables hasta RCE. Significa que cumplen una de las condiciones que acercan el entorno al escenario vulnerable. EL SERVIDOR TAMBIÉN IMPORTA El advisory describe un posible salto desde inclusión local hasta RCE mediante `pearcmd.php` cuando `register_argc_argv` está habilitado. WordPress señala que esta condición puede darse, entre otros casos, en: - imágenes oficiales de PHP para Docker; - determinadas configuraciones por defecto de cPanel con PHP anterior a 8.5. De nuevo, esto no convierte todos esos servidores en comprometidos. Sí demuestra que las precondiciones no son puramente teóricas. YA SE OBSERVAN SONDEOS EN INTERNET La situación cambió pocas horas después de publicarse el parche. Patchstack informó de solicitudes de sondeo que coinciden con la forma concreta de explotación corregida por WordPress. Según Patchstack: - los primeros intentos se observaron el 22 de septiembre de 2026 a las 17:44 UTC; - aparecieron menos de cinco horas después de la publicación del parche; - los intentos observados hasta entonces apuntaban a archivos normales de WordPress Core. Esto es importante porque: SONDEO OBSERVADO ≠ RCE CONFIRMADA Patchstack no afirmó en ese momento que hubiera visto entrega de payloads capaces de ejecutar código arbitrario. Lo que sí demuestra es que terceros comenzaron rápidamente a probar sitios tras analizar el parche. Eso reduce mucho el margen razonable para posponer la actualización. POR QUÉ EL PARCHE REVELA INFORMACIÓN AL ATACANTE Cuando una actualización de seguridad se publica como software abierto, cualquiera puede comparar: - versión vulnerable; - versión corregida. Ese diff puede revelar: - qué función cambió; - qué validación faltaba; - qué entradas podrían manipularse. Patchstack cree que los primeros sondeos se construyeron precisamente a partir de esa diferencia entre versiones. Es un ejemplo claro de por qué, una vez publicado un parche para una vulnerabilidad crítica, la ventana entre “parche disponible” y “pruebas de explotación” puede ser de horas. QUÉ DEBE HACER UN USUARIO NORMAL Si administras un sitio WordPress: 1. Comprueba la versión instalada. 2. Si estás en 7.1.1 o anterior, actualiza inmediatamente a una versión corregida. 3. En la rama actual, el objetivo es WordPress 7.1.2. 4. Si utilizas una rama antigua, instala el backport oficial correspondiente. 5. Verifica después que la actualización se ha aplicado realmente. 6. Comprueba portada, login, formularios, editor y funciones principales. 7. Revisa los registros si el sitio estuvo expuesto antes de actualizar. La actualización oficial es la solución principal. QUÉ DEBE HACER UN ENTORNO CRÍTICO La urgencia es mayor que en una actualización normal. Un flujo razonable es: BACKUP → prueba rápida representativa → STAGING cuando exista → PRODUCCIÓN → verificación inmediata → revisión de logs No conviene convertir “tenemos proceso de pruebas” en una excusa para dejar el sitio vulnerable durante días. La prueba debe ser suficientemente rápida para reducir el tiempo de exposición. QUÉ BUSCAR EN LOS LOGS Sin convertir esta noticia en una guía de explotación, los administradores deberían prestar atención a comportamientos anómalos alrededor de la resolución de páginas y plantillas. Patchstack recomienda especialmente revisar: - solicitudes anómalas con parámetros relacionados con `pagename`; - respuestas de páginas que devuelvan contenido inesperado de archivos de Core; - archivos nuevos o modificados de forma no explicada; - actividad extraña durante la ventana anterior al parche. La ausencia de una alerta no demuestra por sí sola que un sitio no haya sido probado. SI YA ACTUALIZASTE A 7.1.1 Debes volver a actualizar. WordPress 7.1.1 se publicó el 17 de septiembre para corregir 11 vulnerabilidades. WordPress 7.1.2, publicada solo cinco días después, corrige una vulnerabilidad diferente. Por tanto: 7.1.1 → resolvió los problemas de ID88 pero 7.1.2 → añade una corrección crítica nueva La señal anterior debe permanecer en el histórico, pero su recomendación de versión queda supersedida. ESTO ES EXACTAMENTE UNA HISTORIA VIVA ID88 y ID90 muestran cómo debería funcionar RadarAbierto. 17 septiembre → WordPress 7.1.1 → 11 vulnerabilidades → actualizar 22 septiembre → WordPress 7.1.2 → vulnerabilidad crítica nueva → 7.1.1 deja de ser suficiente horas después → terceros empiezan a sondear sitios La información correcta cambia con el tiempo. RA no debería generar dos noticias aisladas y olvidar la anterior. Debe conservar: - qué recomendábamos; - cuándo lo recomendábamos; - qué cambió; - por qué esa recomendación dejó de ser suficiente; - cuál es ahora la acción correcta. LA IMPORTANCIA AUTOMÁTICA VUELVE A FALLAR Cura clasificó automáticamente esta señal como BAJA. Eso no es coherente con la evidencia disponible. La fuente oficial dice: - security release; - critical severity; - update immediately; - ataque sin autenticación; - RCE condicional. Y posteriormente aparece además: - actividad de sondeo observada en Internet. Editorialmente la señal debe elevarse a ALTA. Este caso debe conservarse para calibrar el motor automático de importancia. QUÉ NO SABEMOS TODAVÍA No debe confundirse el sondeo con explotación exitosa. A fecha de esta revisión: - hay actividad de probing observada; - existe un CVE y una puntuación crítica; - el camino hasta RCE depende de precondiciones; - no hay evidencia suficiente en las fuentes revisadas para afirmar que exista ya una campaña masiva de RCE exitosa. RA debe actualizar la señal si esto cambia. A QUIÉN AFECTA Si tienes una web WordPress: comprueba inmediatamente que estás en una versión corregida. Si administras muchas instalaciones: prioriza inventario de versiones y despliegue. Si utilizas hosting gestionado: comprueba que el proveedor realmente ha aplicado el parche. Si utilizas Docker, cPanel o temas con directorios `page-*`: las precondiciones documentadas merecen atención adicional. Si mantienes una rama antigua: usa el backport oficial, pero recuerda que solo la serie más reciente está activamente mantenida. Si trabajas en seguridad: esta vulnerabilidad es especialmente interesante por la rapidez con la que aparecieron sondeos después del parche. RECURSOS Anuncio oficial: https://wordpress.org/news/2026/09/wordpress-7-1-2-release/ Documentación de WordPress 7.1.2: https://wordpress.org/documentation/wordpress-version/version-7-1-2/ Advisory oficial: https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp Seguimiento de sondeos: https://patchstack.com/articles/cve-2026-87902-attackers-started-probing-wordpress-sites-hours-after-the-patch/ Archivo oficial de versiones: https://wordpress.org/download/releases/ QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - si los sondeos evolucionan hacia explotación efectiva; - primeras evidencias independientes de compromisos; - inclusión del CVE en catálogos de explotación conocida; - nuevas técnicas o cadenas asociadas; - cambios en las precondiciones conocidas; - temas y entornos realmente afectados; - respuestas de proveedores de hosting; - nuevas versiones 7.1.x; - disponibilidad y despliegue de backports; - indicadores de compromiso fiables; - campañas masivas; - cambios del advisory oficial; - nuevas mitigaciones; - impacto sobre instalaciones que no puedan actualizar; - tiempo transcurrido entre parche y explotación confirmada. Esta señal debe permanecer como historia viva y supersede la recomendación operativa de ID88. La acción actual ya no es “estar en 7.1.1”, sino estar en WordPress 7.1.2 o en el backport oficial corregido de la rama utilizada.
Por qué puede importarte
WordPress 7.1.2 corrige una vulnerabilidad crítica sin autenticación que puede permitir inclusión de PHP local y, bajo determinadas condiciones, RCE. Afecta a ramas desde 4.7 hasta 7.1.1 y ya se han observado sondeos en Internet, por lo que 7.1.1 deja de ser una versión suficiente.
Cómo ha evolucionado
Primer registro en RadarAbierto: 22/09/2026. Esta entrada actualiza una anterior de la misma historia.
Qué todavía no sabemos
Patchstack ha observado sondeos compatibles con la vulnerabilidad, pero no equivale a explotación RCE confirmada. El salto a RCE requiere precondiciones del tema y servidor. No hay evidencia suficiente en las fuentes revisadas para afirmar todavía una campaña masiva de compromisos. La situación puede cambiar rápidamente.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.