WordPress ya sufre explotación activa de CVE-2026-87902, un RCE crítico
Los atacantes han pasado de sondear sitios vulnerables a escribir archivos que ejecutan comandos de shell, con el tráfico malicioso multiplicado por diez desde el parche de la versión 7.1.2.
El fallo crítico de WordPress CVE-2026-87902 ya se está explotando. Los primeros sondeos aparecieron menos de cinco horas después de que el equipo de seguridad publicara el parche en la versión 7.1.2, y el tráfico malicioso se ha multiplicado por diez desde entonces: los atacantes han pasado de buscar sitios vulnerables a escribir archivos en disco que ejecutan comandos de shell cuando alguien los abre. Se trata de un path traversal sin autenticar que desemboca en ejecución remota de código bajo determinadas condiciones.
La firma Patchstack, especializada en seguridad de WordPress, situó las primeras peticiones maliciosas a las 17:44 UTC del 22 de septiembre, desde un grupo reducido de direcciones IP que apuntaban a varios sitios bajo su protección. El fallo lo descubrió el investigador Robert Ressl y el equipo de WordPress le asigna severidad crítica, 9,2 sobre 10. El aviso de seguridad explica el mecanismo: un atacante sin autenticar puede conseguir que la resolución de plantillas de get_page_template() incluya un archivo .php local y legible situado fuera de los directorios del tema activo.
Las condiciones que hay que cumplir
No basta con tener un WordPress sin actualizar. Para llegar a la ejecución remota hace falta que el tema activo, padre o hijo, tenga un directorio de primer nivel cuyo nombre empiece por page-, como page-templates; que el atacante apunte a un archivo .php local que exista y sea legible por el servidor web; y que ese archivo lo pueda leer la cuenta con la que corre el servicio. El aviso pone pearcmd.php como ejemplo cuando el ajuste register_argc_argv de PHP está activo. Entre los entornos afectados están la imagen oficial de PHP para Docker y la configuración por defecto de cPanel con versiones de PHP anteriores a la 8.5.
Lo que se ve en los registros
La primera fase fue de reconocimiento: los atacantes intentaban incluir archivos del núcleo de WordPress para distinguir qué sitios eran vulnerables. Ahora han entrado en una tercera etapa en la que cambian config-show por config-create, una opción que pearcmd aprovecha para escribir un archivo donde le digan y con el contenido que controle el atacante, según Patchstack. Algunos payloads solo dejan una cadena que marca el host como explotable; otros escriben una etiqueta corta que ejecuta un comando de shell al ser accedida, y ahí ya hay intención clara. Los archivos se dejan en /tmp y /var/tmp con nombres como wp-pear-rce-flag.php, poc87902.php, luci_.php y zeta_.php. La firma no ha publicado un ejemplo de petición funcional, pero avisa de que los sondeos usan secuencias de traversal con doble codificación en 'pagename' junto a un 'page_id' válido. Las IP de origen que conviene bloquear son 169.58.48.193, 169.58.48.195 y 2001:df1:e8c0::106b.
WordPress cerró el agujero con la versión 7.1.2 y ha llevado el arreglo hacia atrás hasta la rama 4.7 por la gravedad del asunto. Las versiones anteriores a la 4.6 no van a recibir parche. Con explotación activa sobre la mesa, toca actualizar cuanto antes y repasar los registros en busca de los nombres de archivo y las IP de arriba.
