WordPress ha corregido una vulnerabilidad crítica en su software base que permite a un atacante sin cuenta hacer que un sitio cargue un archivo PHP desde fuera de las carpetas de temas. En algunos servidores, esto puede ir más allá y permitir al atacante ejecutar su propio código. La solución se distribuyó el 22 de septiembre en WordPress 7.1.2, con parches para todas las ramas que el proyecto aún soporta, hasta la 4.7, y WordPress insta a los propietarios de sitios a actualizar de inmediato.
WordPress califica la falla como crítica, le asigna una puntuación CVSS de 9.2 y el identificador CVE-2026-87902. Para explotarla no se requiere cuenta ni acción de un usuario autenticado.
Todas las versiones desde la 4.7.0 hasta la 7.1.1 están afectadas. Esto incluye la 7.1.1, de la versión de seguridad del 17 de septiembre, por lo que un sitio actualizado hace menos de una semana aún necesita esta nueva actualización. Se trata de una falla distinta de las que corrigió esa versión.
La versión a la que se debe actualizar depende de la rama que se ejecute:
- WordPress ha aplicado el parche a todas las ramas antiguas que aún soporta, hasta la 4.7.37, como cortesía. La lista completa está en las notas de la versión.
- Los sitios con actualizaciones automáticas en segundo plano habilitadas comenzarán la actualización automáticamente. Otros pueden actualizar desde el panel de control en Actualizaciones, o descargar la versión desde WordPress.org. WordPress no ofrece un método alternativo, por lo que actualizar es la solución.
Cargar un archivo PHP local ejecuta lo que ese archivo ya hace. Convertir eso en código elegido por el atacante requiere una segunda condición: el servidor debe tener ya un archivo PHP que haga algo útil al cargarse. Eso es lo que WordPress describe como "algunos servidores", y es la razón por la que la falla no significa ejecución de código completa en todos los sitios afectados.
La falla está en cómo WordPress elige el archivo de plantilla para una página. Uno de los nombres de archivo que construye proviene de parte de la dirección web y, en las versiones afectadas, WordPress no pasaba ese valor por su propia comprobación de rutas con ../, la comprobación que el código vecino ya utilizaba.
Debido a que el nombre se construye como page-{valor}.php, un ataque exitoso también requiere que el tema activo tenga una carpeta de nivel superior cuyo nombre comience con page-, y que el archivo objetivo termine en .php. Algunos temas, incluidos los temas predeterminados antiguos de WordPress, incluyen una carpeta que cumple con esto.
El proveedor de seguridad Patchstack, en su propio análisis, señala dos comprobaciones que indican al propietario de un sitio cuán expuesto está: si el tema activo tiene una carpeta de nivel superior cuyo nombre empieza por page-, y si PHP se ejecuta con una configuración llamada register_argc_argv activada, de la que depende una técnica conocida de ejecución de código.
Ninguna de las dos es una solución, según la empresa, pero ambas muestran cuán cerca está un sitio del peor escenario. Esa configuración está desactivada por defecto en PHP 8.5 y activada por defecto en versiones anteriores de PHP.
Hasta el 22 de septiembre, no había informes de que la falla se estuviera utilizando en ataques, ni un exploit de prueba de concepto público, ni una entrada en el catálogo de vulnerabilidades explotadas conocidas de la CISA de Estados Unidos.
WordPress atribuyó a Robert Ressl el descubrimiento y reporte de la falla. The Hacker News se ha puesto en contacto con WordPress y con Ressl para obtener comentarios.
Deja una respuesta