Ir al contenido

El medio de los artesanos de la web martes, 29 de septiembre de 2026

MailStudio
Seguridad

WordPress: un fallo crítico bajo ataque activo cinco días después de su parche

Corregido el 22 de septiembre en WordPress 7.1.2, el fallo CVE-2026-87902 sufre un rastreo masivo: más de 30 000 direcciones IP sondearon sitios en cinco días, según CrowdSec.

El 22 de septiembre de 2026, WordPress publicó la versión 7.1.2 para corregir CVE-2026-87902, un fallo crítico de inclusión de archivos locales en el motor de resolución de plantillas de página. Menos de doce horas después, ya se registraban los primeros intentos de explotación. Cinco días más tarde, un informe de CrowdSec cifra el rastreo en más de 30 000 direcciones IP distintas, un ritmo que confirma que el parche por sí solo no basta para proteger los sitios.

Un fallo sin autenticación en el núcleo de WordPress

Clasificado como CWE-98 (control incorrecto del nombre de archivo usado en un include) y valorado con 9.2 en CVSS 4.0 por WordPress.org, CVE-2026-87902 permite a un atacante no autenticado manipular la resolución de plantillas de página para forzar la inclusión de un archivo PHP local situado fuera del directorio del tema activo. Según la configuración del servidor, esta inclusión local puede derivar en ejecución remota de código. Todas las versiones de WordPress desde la 4.7.0 hasta la 7.1.1 están afectadas.

Cronología de una explotación exprés

FechaSuceso
22 de septiembre, mañanaPublicación de WordPress 7.1.2, con retroportados hasta la rama 4.7.37
22 de septiembre, 11:49 UTCPrimer intento de explotación registrado por Patchstack, el mismo día del parche
24 de septiembreExplotación activa confirmada en el entorno real
23 al 27 de septiembre30 813 direcciones IP únicas que enviaron solicitudes maliciosas, según CrowdSec

El informe de CrowdSec sitúa la mayor parte del volumen de rastreo en Estados Unidos (22 %) e Irán (20 %), seguidos de Lituania, Países Bajos y Francia. Este reparto por país de origen de las solicitudes no indica la nacionalidad de los atacantes: la mayoría de estas direcciones pertenecen a servidores o dispositivos ya comprometidos, usados como intermediarios.

Algunos administradores desactivan deliberadamente las actualizaciones automáticas de WordPress, lo que los deja en primera línea durante toda la ventana de corrección.

Por qué la actualización automática no siempre basta

WordPress corrige fallos críticos mediante actualizaciones automáticas menores desde hace años, pero esa protección depende de un ajuste que muchos proveedores de hosting y agencias desactivan para mantener el control del despliegue. Los entornos de preproducción, las copias de staging y las instancias en contenedor a menudo escapan a ese mecanismo y permanecen vulnerables más tiempo que el sitio de producción que deberían replicar, un punto sensible para quien gestiona un WordPress autoalojado con varias copias activas.

Un parche virtual mediante un firewall de aplicaciones web (CrowdSec AppSec u otra herramienta equivalente del proveedor de hosting) no sustituye la actualización: gana tiempo mientras el parche se despliega en todo el parque, staging incluido.

Reforzar la configuración de PHP como segunda capa

Más allá de actualizar a la 7.1.2 o a una rama corregida, las recomendaciones también apuntan a la configuración PHP del servidor, en particular a la directiva register_argc_argv y a la presencia del script pearcmd.php, dos elementos que facilitan la explotación de fallos de inclusión de archivos en una base mal reforzada.

; php.ini — reducir la superficie de ataque de las inclusiones de archivo
register_argc_argv = Off
disable_functions = exec,shell_exec,system,passthru,proc_open
allow_url_include = Off

Esta base coincide con los principios ya detallados en un hardening mínimo de WordPress: limitar lo que PHP puede ejecutar, separar entornos y comprobar que la versión corregida es realmente la que está en marcha, copias de staging incluidas.

Lo esencial

CVE-2026-87902 afecta al núcleo de WordPress, no requiere autenticación y sufre un rastreo activo y masivo desde su divulgación. Actualizar a la 7.1.2 o a una rama corregida es la medida prioritaria, y conviene verificarla en cada entorno (producción, staging, contenedores), no solo en el sitio visible públicamente.

Este tipo de fallo recuerda por qué recomiendo sistemáticamente tratar las copias de staging como objetivos por derecho propio: suele ser la preproducción, olvidada por las actualizaciones automáticas, la que sirve de puerta de entrada hacia la infraestructura que aloja el sitio público. — Simon Janvier

Para saber más: el informe completo de CrowdSec sobre la explotación de CVE-2026-87902 está disponible en crowdsec.net.

Compartir LinkedIn Bluesky Hacker News E-mail

Leer también