WordPress publicó el 22 de septiembre de 2026 la versión 7.1.2, una actualización exclusivamente de seguridad que corrige una vulnerabilidad crítica registrada como CVE-2026-87902. El fallo afecta a la resolución de plantillas de página y puede, bajo ciertas condiciones, derivar en ejecución remota de código sin autenticación. El parche se ha retroportado hasta la rama 4.7, y ya circula una prueba de concepto pública: actualizar no es opcional.
Qué corrige la versión 7.1.2
El fallo reside en get_page_template(), la función encargada de resolver qué archivo de plantilla cargar para una página determinada. Un atacante no autenticado puede manipular los parámetros de resolución para que WordPress incluya un archivo PHP legible situado fuera de los directorios del tema activo. Según la configuración del servidor y el tema activo, esa inclusión local de archivo puede escalar a ejecución remota de código.
El fallo fue reportado por el investigador Robert Ressl y documentado como GHSA-7hp8-65ch-5whp. Tiene una puntuación CVSS v3.1 de 8,1 y CVSS v4.0 de 9,2 (crítico), diferencia que refleja lo fácil que resulta explotarlo sin interacción del usuario bajo el modelo de puntuación más reciente.
| Rama | Versión corregida | Vulnerable antes de |
|---|---|---|
| 7.1.x | 7.1.2 | 7.1.0 a 7.1.1 |
| 7.0.x | 7.0.6 | 7.0.0 a 7.0.5 |
| 6.9.x | 6.9.9 | Versiones anteriores |
| 4.7.x y ramas antiguas | 4.7.37 y equivalentes | Parche retroportado a todas las ramas soportadas |
Un exploit ya documentado públicamente
Un punto de atención adicional: un repositorio de prueba de concepto que detalla el ataque se publicó casi al mismo tiempo que el parche, lo que acorta la ventana entre la divulgación y la explotación real. Mail Studio no reproduce aquí ningún código ni paso de explotación; lo relevante para los administradores de sitios es la rapidez de la actualización, no el detalle técnico del ataque.
Bajo ciertas condiciones de servidor y tema activo, la inclusión local de archivo documentada como CVE-2026-87902 puede escalar a ejecución remota de código sin autenticación.
Cómo comprobar y forzar la actualización
La mayoría de las instalaciones con actualizaciones automáticas activadas ya han cambiado en segundo plano. Los sitios administrados manualmente, o alojados donde el proveedor desactiva las actualizaciones menores automáticas, necesitan una comprobación explícita.
# Comprobar la versión instalada
wp core version
# Forzar la actualización a la última versión menor
wp core update
# Confirmar después
wp core versionSin acceso a WP-CLI, el panel de administración (Actualizaciones) muestra el mismo aviso y aplica el parche con un clic. Reiniciar la caché de objetos o un proxy frontal (Varnish, Cloudflare) tras actualizar evita servir de nuevo una respuesta generada por el código vulnerable.
Un parche retroportado hasta la rama 4.7 indica un defecto presente en el núcleo desde hace mucho tiempo. Los sitios que corren versiones muy antiguas, a veces mantenidos sin vigilancia activa, son los más expuestos: es el momento de comprobar que ninguna instalación olvidada sigue funcionando sin actualizaciones automáticas.
Los sitios que exponen temas de terceros poco mantenidos, o cuya configuración de servidor es permisiva con la lectura de archivos PHP fuera del directorio activo, merecen una comprobación manual incluso tras actualizar: el parche corrige la causa en el núcleo, pero una base mínima de hardening reduce aún más la superficie de ataque, en particular en permisos de archivos y restricciones de ejecución PHP por directorio.
Para los sitios autoalojados
Las instalaciones gestionadas mediante un panel como CloudPanel no siempre aplican las actualizaciones menores de WordPress por defecto, a diferencia de un hosting compartido gestionado. En este tipo de infraestructura, descrita en la guía sobre autoalojar WordPress con CloudPanel, la comprobación manual descrita arriba es la única garantía de cobertura rápida.
Lo que hay que recordar
WordPress 7.1.2 corrige un fallo crítico de inclusión local de archivos, explotable sin autenticación bajo ciertas condiciones, con una prueba de concepto ya pública. El parche llega hasta la rama 4.7. La prioridad inmediata es actualizar; el hardening del servidor sigue siendo la defensa en profundidad que limita el impacto del próximo fallo de esta familia.
Una divulgación acompañada de un repositorio de prueba de concepto casi simultáneo ya no es la excepción en los fallos de WordPress de alto impacto, se ha convertido en la norma. He visto demasiados sitios de clientes quedar vulnerables durante semanas porque la actualización automática se desactivó «temporalmente» para una prueba y luego se olvidó. Un cron semanal que compare wp core version con el feed RSS de lanzamientos de seguridad cuesta diez minutos de configurar y evita justamente este tipo de sustos — Simon Janvier.
Para saber más: el aviso de seguridad completo está disponible en GitHub Security Advisories (GHSA-7hp8-65ch-5whp) y el anuncio oficial en wordpress.org/news.
