Publicado el 24 septiembre 2026 · Equipo mitza.es
WordPress publicó el 22 de septiembre de 2026 la versión 7.1.2, que corrige CVE-2026-87902, una vulnerabilidad crítica con puntuación CVSS de 9,2 sobre 10. Lo llamativo no es solo la gravedad: el fallo afecta a todas las versiones de WordPress publicadas entre la 4.7.0 y la 7.1.1, es decir, prácticamente una década de instalaciones, desde finales de 2016 hasta el parche de este mes.
Dónde está el fallo y por qué no hace falta contraseña
El problema está en get_page_template(), la función que WordPress usa para decidir qué archivo de plantilla del tema debe cargar para una página. Una validación insuficiente de los caracteres de traversal de ruta (../) en valores derivados de la URL permite a un atacante desviar esa búsqueda hacia archivos .php fuera de la carpeta del tema. No se necesita cuenta, contraseña ni ninguna acción de un usuario ya autenticado: el ataque llega directamente desde una petición HTTP normal.
Qué versiones quedan protegidas
- Rama 7.1.x: actualizar a 7.1.2.
- Rama 7.0.x: actualizar a 7.0.6.
- Rama 6.9.x: actualizar a 6.9.9.
- Rama 6.8.x: actualizar a 6.8.10.
- Rama 6.7.x: actualizar a 6.7.9.
- Rama 6.6.x y anteriores, hasta 4.7: actualizar a 6.6.9 o a la versión de mantenimiento equivalente, hasta la 4.7.37.
La explotación empezó en horas, no en días
La firma de seguridad Patchstack detectó las primeras peticiones maliciosas contra sitios vulnerables a las 17:44 UTC del propio 22 de septiembre, menos de cinco horas después de publicarse el parche. En menos de un día, el volumen de tráfico de ataque se multiplicó por diez, con atacantes que ya no solo tanteaban el fallo, sino que escribían archivos PHP maliciosos en el servidor para ejecutar comandos. El investigador que encontró el fallo, Robert Ressl, publicó una prueba de concepto el mismo día del parche, lo que aceleró la carrera entre quien actualiza y quien ataca.
Cuándo el fallo se convierte en ejecución remota de código
La carga de archivos ajenos al tema es grave por sí sola, pero convertirla en ejecución remota de código requiere que se den tres condiciones a la vez: que el tema activo tenga una carpeta cuyo nombre empiece por page- (por ejemplo, page-templates), que exista en el servidor un archivo .php legible por el usuario del servidor web, y que ese archivo pueda ejecutar código a partir de parámetros externos, como ocurre con pearcmd.php de PEAR cuando register_argc_argv está activado. Sin esas tres condiciones, el riesgo inmediato es menor, pero un atacante sigue pudiendo leer archivos del servidor a los que no debería tener acceso, así que actualizar sigue siendo la prioridad independientemente de la configuración concreta de cada web.
Qué hacer si tienes una web en WordPress
Actualiza a la versión parcheada de tu rama cuanto antes; si tu instalación lleva tiempo sin tocarse y está por debajo de 4.7.37, sáltate directamente a la última versión estable. No es la primera vez este año que el núcleo de WordPress protagoniza un aviso de este calibre: en julio ya cubrimos la cadena de fallos wp2shell, y el patrón se repite: cuanto más tarda una pyme en actualizar, más tiempo queda expuesta a algo que ya tiene solución publicada. Nuestro servicio de mantenimiento informático incluye la revisión y actualización de instalaciones WordPress, y si tu web arrastra una instalación difícil de mantener, también podemos plantear un desarrollo a medida más controlado desde cero.