Los atacantes pasaron de escanear sitios de WordPress afectados por la vulnerabilidad crítica CVE-2026-87902 a explotarla activamente para escribir archivos en el servidor y ejecutar comandos de shell al acceder a ellos. La empresa de seguridad Patchstack observó un fuerte aumento de la actividad horas después de que WordPress publicara el parche en la versión 7.1.2.
Del reconocimiento a la ejecución de la carga útil
La actividad inicial del ataque, que parecía estar destinada a identificar sitios vulnerables, comenzó menos de cinco horas después de la publicación del parche. Según Patchstack, las primeras solicitudes maliciosas se registraron a las 17:44 UTC del 22 de septiembre, procedentes de un pequeño grupo de direcciones IP que apuntaron a varios sitios protegidos.
Al día siguiente, la actividad relacionada con la vulnerabilidad aumentó diez veces e incluyó una fase de escritura de archivos en el disco. Algunas solicitudes intentaron incluir archivos normales del núcleo de WordPress, aparentemente para detectar sitios explotables, antes de pasar al envío de cargas útiles maliciosas.
Naturaleza de la vulnerabilidad y condiciones de explotación
El investigador de seguridad Robert Ressl descubrió un fallo no documentado relacionado con una evasión de rutas, que puede permitir la ejecución remota de comandos en determinadas circunstancias. La vulnerabilidad concede a un atacante no autenticado la capacidad de hacer que la función get_page_template() incluya localmente un archivo PHP legible situado fuera de los directorios de la plantilla activa. El equipo de seguridad de WordPress evaluó su gravedad con una puntuación de 9,2 sobre 10.
El acceso a la ejecución de comandos requiere condiciones específicas, entre ellas la existencia de un directorio de nivel superior cuyo nombre comience por page- dentro de la plantilla principal o secundaria activa, así como un archivo PHP local legible por la cuenta del servidor web. El aviso oficial menciona pearcmd.php como ejemplo cuando está habilitada la configuración register_argc_argv.
El aviso también confirmó que la imagen oficial de PHP utilizada con Docker está afectada, además de la configuración predeterminada de cPanel cuando se utiliza una versión de PHP anterior a la 8.5.
¿Qué están haciendo ahora los atacantes?
Patchstack observó solicitudes que utilizan la herramienta pearcmd para pasar de la función config-show a config-create, lo que permite escribir un archivo en una ubicación elegida por el atacante y con contenido bajo su control. Algunos archivos solo tenían como objetivo colocar una marca que demostrara que el servidor era explotable, pero los investigadores de la empresa también observaron archivos que contenían una etiqueta corta que ejecutaba un comando de shell al abrir el archivo.
Los archivos observados se colocaron en las rutas /tmp y /var/tmp, y tenían nombres como wp-pear-rce-flag.php, poc87902.php, luci_<random>.php y zeta_<random>.php. La empresa no publicó una solicitud práctica completa, pero afirmó que los intentos utilizan secuencias de evasión de rutas codificadas dos veces dentro de pagename, junto con un valor válido de page_id.
¿Qué se debe hacer?
WordPress publicó la versión 7.1.2 para solucionar CVE-2026-87902, y la corrección también se incorporó a las ramas hasta la versión 4.7 debido a la gravedad de la vulnerabilidad. Las versiones anteriores a la 4.6 no recibirán una corrección para ella.
Los administradores de sitios deben actualizar a la versión 7.1.2 lo antes posible y, después, revisar los registros en busca de solicitudes sospechosas y archivos PHP inusuales en las rutas /tmp y /var/tmp. Patchstack también mencionó direcciones que pueden añadirse a listas de bloqueo: 169.58.48.193, 169.58.48.195 y 2001:df1:e8c0::106b.
La importancia de este desarrollo radica en que la ventana de transición del reconocimiento a la explotación efectiva no superó aproximadamente un día, lo que hace insuficiente depender únicamente de la monitorización en los sitios que no hayan confirmado su actualización. La capacidad de ejecutar comandos sigue estando vinculada a condiciones específicas de las plantillas, los archivos PHP y la configuración del entorno, pero la actividad observada demuestra que la vulnerabilidad ya no es solo un riesgo teórico.