Seguir WordPress ha lanzado una actualización de seguridad de emergencia que aborda una vulnerabilidad crítica en su software central, que puede permitir a un atacante no autenticado cargar archivos PHP locales arbitrarios y, bajo condiciones específicas de servidor y tema, lograr la ejecución remota de código. Registrada como CVE-2026-87902, la vulnerabilidad afecta a las versiones de WordPress desde la 4.7.0 hasta la 7.1.1 y posee una puntuación CVSS 4.0 de 9.2.
El fallo reside en la resolución de plantillas de página de WordPress. Un atacante puede manipular el valor que utiliza WordPress al seleccionar una plantilla de página y provocar que get_page_template() incluya un archivo PHP legible fuera de los directorios del tema activo. No se requiere cuenta de WordPress, cookie de autenticación, interacción del administrador o plugin vulnerable para el ataque subyacente de inclusión de archivo.
La ejecución remota de código es condicional y no universal. El tema activo debe contener una estructura de directorio compatible y el servidor debe exponer un archivo PHP legible que pueda ser abusado al incluirse. El ataque demostrado públicamente utilizó pearcmd.php de PEAR en un entorno donde la configuración register_argc_argv de PHP estaba habilitada.
WordPress lanzó la versión 7.1.2 el 22 de septiembre de 2026, específicamente para abordar la vulnerabilidad y ha retroportado correcciones a las ramas de seguridad mantenidas, desde WordPress 4.7. Se aconseja encarecidamente a los administradores de sitios que actualicen de inmediato.
Análisis de CVE-2026-87902
La vulnerabilidad se origina en cómo el Core de WordPress resuelve las plantillas para las páginas. Cuando un visitante solicita una página, WordPress construye una lista de posibles nombres de archivos de plantillas y busca en el tema activo un archivo coincidente.
En las versiones vulnerables, los datos controlados por el atacante utilizados durante este proceso no están suficientemente restringidos antes de ser incorporados en la ruta de la plantilla de la página. Por lo tanto, una solicitud elaborada puede introducir secuencias de salto de directorio y provocar que WordPress resuelva un archivo PHP que reside fuera de los directorios esperados del tema activo.
La clave detalles de CVE-2026-87902 es que el primitivo fundamental es la inclusión de archivos locales, no la ejecución arbitraria y desinhibida de código. WordPress describe oficialmente el problema como permitir que un atacante no autenticado haga que la resolución de plantillas de página incluya un archivo .php local legible fuera de los directorios de temas. RCE se hace posible solo cuando se cumplen requisitos ambientales adicionales.
Un tema vulnerable debe contener un directorio de nivel superior cuyo nombre comience con page-, tal como:
page-templates
El aviso de WordPress identifica los temas heredados Twenty Twelve y Twenty Fourteen entre los que cumplen este requisito estructural. Temas populares de terceros como Neve, Hestia y Sydney también pueden contener estructuras de directorio compatibles.
Una segunda condición es que el atacante debe identificar un archivo PHP local legible por la cuenta del servidor web que produzca un comportamiento útil al incluirse.
El investigador de seguridad Robert Ressl demostró la trayectoria de RCE utilizando un componente PEAR llamado pearcmd.php. Para que esa técnica funcione, la opción register_argc_argv de PHP también debe estar habilitada. La imagen oficial de Docker de PHP puede cumplir con las condiciones relevantes, mientras que configuraciones tradicionales de cPanel que utilizan versiones de PHP anteriores a 8.5 también pueden exponer el entorno requerido.
Esta distinción es importante porque no todas las instalaciones de WordPress vulnerables son explotables inmediatamente para la ejecución arbitraria de código. Un sitio puede contener el código central vulnerable sin tener la estructura de temas o el entorno PHP requerido por la cadena de explotación demostrada.
No obstante, el primitivo de inclusión de archivo local por sí mismo cruza un importante límite de seguridad y no requiere autenticación ni interacción del usuario.
CVE-2026-87902 afecta WordPress Core desde la versión 4.7.0 hasta 7.1.1. El aviso oficial lista las ramas vulnerables individualmente, incluyendo:
- WordPress 7.1.0–7.1.1
- WordPress 7.0.0–7.0.5
- WordPress 6.9.0–6.9.8
- WordPress 6.8.0–6.8.9
- WordPress 6.7.0–6.7.8
- WordPress 6.6.0–6.6.8
- Todas las ramas afectadas correspondientes hasta WordPress 4.7.36
WordPress 7.1.1, lanzado solo cinco días antes como una actualización de seguridad, sigue siendo vulnerable a este problema separado.
La vulnerabilidad fue descubierta por el investigador de seguridad Robert Ressl y reportada de manera privada a través del programa HackerOne de WordPress el 20 de julio de 2026. WordPress reconoció el informe el 21 de julio e informó al investigador el 15 de septiembre que se planeaba una solución. El parche y el aviso público se publicaron el 22 de septiembre.
WordPress clasifica la vulnerabilidad como Crítica con una puntuación CVSS 4.0 de 9.2. Su vector refleja un ataque accesible por red con baja complejidad, sin privilegios requeridos y sin interacción del usuario, al mismo tiempo que registra que deben estar presentes requisitos adicionales de ataque antes de que sea posible el máximo impacto demostrado.
Un PoC público de CVE-2026-87902 fue lanzado por el investigador junto con la divulgación. La prueba de concepto incluye un laboratorio local reproducible y demuestra el camino desde la transversalidad de plantillas no autenticada hasta la inclusión local de PHP y RCE condicional. El investigador probó el exploit contra WordPress 7.0.2 en entornos aislados y no lo probó contra sitios de producción en vivo.
La ejecución exitosa en el entorno demostrado ocurrió con los privilegios de la cuenta PHP/servidor web, identificada como www-data, en lugar de proporcionar automáticamente privilegios de root del sistema operativo. Por lo tanto, el impacto práctico depende en parte de los permisos asignados al proceso del servidor web.
Un atacante que logra la ejecución de código PHP podría potencialmente desplegar una shell web, modificar archivos del sitio web, robar datos de configuración de WordPress y credenciales de base de datos, crear persistencia, alterar contenido, redirigir visitantes o usar el sitio comprometido como un punto de partida inicial para ataques adicionales. Estas son consecuencias potenciales post-explotación más que actividades actualmente atribuidas a una campaña del mundo real de CVE-2026-87902.
En el momento de la divulgación original el 22 de septiembre, no se había informado de explotación en el medio y el registro de enriquecimiento de CISA listaba la explotación como nula.
Sin embargo, el panorama de amenazas comenzó a cambiar a las pocas horas de la divulgación. Patchstack informó haber detectado intentos de sondeo aproximadamente a las 17:44 UTC del 22 de septiembre, menos de cinco horas después de que WordPress 7.1.2 estuvo disponible. Las solicitudes observadas coincidían con la codificación abordada por el parche, sugiriendo un rápido análisis de la diferencia de seguridad.
Importante, Patchstack caracterizó el tráfico observado como sondeo más que entrega exitosa de carga útil. Las solicitudes intentaron incluir archivos PHP ordinarios del Core de WordPress y no demostraron ejecución de código controlado por el atacante. A partir del 23 de septiembre, la evidencia disponible públicamente por lo tanto apoya el reconocimiento activo, pero no se ha confirmado explotación exitosa en entornos de producción.
Actualmente no hay IOCs de CVE-2026-87902 específicos de campaña como dominios maliciosos, hashes de archivos, familias de malware o un conjunto definido de infraestructura atacante. Los defensores deben centrarse en los patrones de solicitudes HTTP asociados con la transversalidad de plantillas de página anómala y la actividad subsiguiente en el sistema de archivos o PHP.
Las posibles señales de advertencia incluyen:
- Solicitudes que contengan secuencias de salto de directorio codificadas o repetidas
- Solicitudes que intenten manipular la selección de plantillas de página
- Patrones de acceso que involucren nombres de archivos PHP locales inesperados
- Nuevos archivos PHP que aparezcan en directorios de WordPress grabables
- Procesos secundarios inesperados lanzados por la cuenta PHP o servidor web
- Conexiones salientes inexplicadas que se originan desde trabajadores PHP
- Nuevas cuentas de administrador o cambios no autorizados a contenido de WordPress
- Modificaciones a temas, plugins o archivos Core después de solicitudes HTTP sospechosas
Debido a que la información de explotación pública ahora está disponible, las organizaciones deben esperar un escaneo más amplio y el desarrollo automatizado de explotaciones, aunque aún no se ha confirmado públicamente el compromiso exitoso en el mundo real.
Mitigación de CVE-2026-87902
La remediación principal es instalar de inmediato una versión parcheada de WordPress. WordPress afirma que la última rama, WordPress 7.1.2, contiene la solución de seguridad, y también se han creado versiones parcheadas para ramas más antiguas.
Las versiones corregidas oficialmente incluyen:
- 7.1 → 7.1.2
- 7.0 → 7.0.6
- 6.9 → 6.9.9
- 6.8 → 6.8.10
- 6.7 → 6.7.9
- 6.6 → 6.6.9
- 6.5 → 6.5.12
- 6.4 → 6.4.12
- 6.3 → 6.3.12
- 6.2 → 6.2.13
- 6.1 → 6.1.14
- 6.0 → 6.0.16
Las retroportaciones de seguridad continúan a través de WordPress 4.7.37. Sin embargo, WordPress enfatiza que solo la versión más reciente de WordPress está soportada activamente, por lo tanto, es preferible actualizar a la rama actual donde sea operativamente factible.
Los sitios que admiten actualizaciones automáticas en segundo plano deberían comenzar a recibir el lanzamiento de seguridad automáticamente. Los administradores pueden verificar e instalar manualmente la actualización a través de:
Panel de WordPress → Actualizaciones → Actualizar ahora
WordPress no proporciona una solución alternativa completa que reemplace la instalación de la actualización de seguridad.
Detectar CVE-2026-87902 debería comenzar identificando todas las instalaciones de WordPress que ejecuten versiones del Core 7.1.1 o anteriores y luego determinar si su tema padre o hijo activo contiene un directorio de nivel superior que comience con page-.
Los administradores también deben determinar si PHP se está ejecutando con:
register_argc_argv = On
y si existen componentes PEAR legibles, como pearcmd.php u otros puntos de entrada PHP locales potencialmente útiles en el servidor. Estas revisiones ayudan a evaluar la exposición a técnicas de RCE conocidas, pero no determinan si el fallo subyacente de WordPress existe.
To Para detectar sondeo o intento de explotación de CVE-2026-87902, los equipos de seguridad deben inspeccionar la telemetría del servidor web, WAF, proxy inverso, PHP y WordPress para: Patrones de recorrido ../ codificados o equivalentes en solicitudes de frontend
- Solicitudes que intenten manipular la resolución de plantillas de página de WordPress
- Referencias inusuales a archivos .php fuera de los directorios de temas activos
- Solicitudes que intenten alcanzar componentes PHP relacionados con PEAR
- Ráfagas de solicitudes de recorrido similares desde una fuente
- Trabajadores PHP lanzando inesperadamente comandos de shell o utilidades del sistema
- Nuevos archivos PHP o shells web apareciendo después de solicitudes sospechosas
- Cambios inesperados en wp-config.php, temas, plugins o cargas
- Cuentas de administrador de WordPress recién creadas
- Tráfico saliente sospechoso que se origina desde el servidor web
- El escaneo observado por Patchstack muestra que los sitios de WordPress accesibles por Internet ya pueden recibir sondeos específicos de la vulnerabilidad, haciendo que la telemetría web y WAF sea particularmente valiosa para la investigación retrospectiva.
Los administradores que no puedan parchear de inmediato pueden reducir la exposición a la cadena de ejecución basada en PEAR demostrada deshabilitando register_argc_argv para las solicitudes web cuando no es necesario y eliminando componentes PEAR legibles por la web que no se utilizan. Robert Ressl enfatiza que estas solo son medidas de endurecimiento; no solucionan la vulnerabilidad subyacente de WordPress.
Las organizaciones también pueden reducir el impacto potencial de post-explotación asegurando que la cuenta PHP/servidor web siga los principios de privilegio mínimo. No debe tener acceso de escritura innecesario a directorios del sistema o archivos de aplicación sensibles.
Los sitios que eran accesibles por Internet antes del parcheo deben ser revisados por solicitudes sospechosas que comiencen alrededor de la divulgación pública del 22 de septiembre, particularmente porque el material PoC público se hizo disponible al mismo tiempo y los sondeos siguieron en pocas horas.
Si se identifica una explotación sospechosa, los administradores deben preservar los registros relevantes y realizar una revisión completa de integridad de:
Archivos Core de WordPress
- Temas activos e inactivos
- El directorio de cargas
- El directorio de cargas
- Configuración del servidor web
- Configuración del servidor web
- Tareas programadas y entradas del cron
- Cuentas de administrador de WordPress
- Procesos de PHP y archivos recientemente creados
- Las contraseñas de bases de datos, claves de API, secretos de aplicación u otras credenciales potencialmente expuestas guardadas en archivos legibles deben rotarse si la investigación indica que un atacante logró la inclusión de archivos locales o la ejecución de código.
La prioridad inmediata sigue siendo actualizar el propio WordPress. Los cambios en el tema, deshabilitar PEAR o modificar la configuración de PHP pueden reducir rutas particulares de explotación, pero no deben ser tratados como sustitutos al lanzamiento de seguridad oficial.
¿Qué es CVE-2026-87902 y cómo funciona?
FAQ
CVE-2026-87902 es una vulnerabilidad crítica de recorrido de ruta y de inclusión de archivo PHP local no autenticada en la resolución de plantillas de página de WordPress Core. Una solicitud elaborada en el frontend puede causar que get_page_template() incluya un archivo PHP legible fuera de los directorios de temas activos. Si la estructura de tema requerida y las condiciones de PHP del lado del servidor también están presentes, la inclusión se puede convertir en ejecución remota de código.
¿Cuándo se descubrió por primera vez CVE-2026-87902?
El investigador de seguridad Robert Ressl presentó la vulnerabilidad de manera privada a WordPress a través de HackerOne el 20 de julio de 2026, y WordPress reconoció el informe al día siguiente. El equipo de seguridad lanzó el parche y el aviso público el 22 de septiembre de 2026.
¿Cuál es el impacto de CVE-2026-87902 en los sistemas?
La vulnerabilidad permite a un atacante remoto no autenticado incluir un archivo PHP local legible elegido. Bajo condiciones ambientales adecuadas, esto puede resultar en la ejecución de código PHP con los privilegios de la cuenta del servidor web. Las consecuencias potenciales incluyen modificación del sitio web, robo de credenciales, persistencia, instalación de shell web y compromiso adicional de recursos accesibles al proceso PHP afectado.
¿Puede CVE-2026-87902 aún afectarme en 2026?
Sí. Las instalaciones de WordPress desde la versión 4.7.0 hasta la 7.1.1 siguen siendo vulnerables hasta que se instale la versión parcheada correspondiente. El material público de prueba de concepto está disponible, y se observó sondeo específico de la vulnerabilidad dentro de horas de la divulgación, aunque aún no se había confirmado públicamente una explotación exitosa en entornos de producción hasta el 23 de septiembre.
¿Cómo puedo protegerme de CVE-2026-87902?
Actualice inmediatamente a WordPress 7.1.2 o a la versión parcheada para su rama mantenida. Los administradores también deben revisar el tráfico HTTP histórico para detectar intentos de recorrido, inspeccionar el sitio en busca de archivos PHP no autorizados o cambios de configuración, y considerar deshabilitar funcionalidad innecesaria de register_argc_argv y eliminar componentes PEAR no utilizados como medidas adicionales de endurecimiento.
Upgrade immediately to WordPress 7.1.2 or the patched version for your maintained branch. Administrators should also review historical HTTP traffic for traversal attempts, inspect the site for unauthorized PHP files or configuration changes, and consider disabling unnecessary register_argc_argv functionality and removing unused PEAR components as additional hardening measures.
