WordPress: falla CVE-2026-119977 permite RCE durante la actualización del núcleo
WordPress corrige CVE-2026-119977: una ejecución remota de código que ocurre justo cuando el sitio se actualiza
El WordPress 7.1.4, publicado el 28 de octubre de 2026, corrige 22 vulnerabilidades del núcleo. Una de ellas, CVE-2026-119977, permite que un atacante sin cuenta ejecute código PHP en el servidor, y ya se está explotando. Afecta a todas las versiones desde la 4.7 hasta la 7.1.3. El identificador CVE se asignó recién este 31 de octubre, tres días después del parche.
Qué ocurre exactamente
Es una condición de carrera de tipo TOCTOU (CWE-367) en el actualizador del núcleo. Cuando WordPress instala un paquete completo, descomprime los archivos nuevos en una carpeta con nombre predecible dentro de wp-content/upgrade. Esa copia temporal incluye el instalador de WordPress, por ejemplo wp-admin/setup-config.php.
Si el servidor permite acceso web y ejecuta PHP en esa carpeta, un atacante que pida el instalador en el momento justo puede interactuar con esa copia y avanzar hasta ejecutar código con los privilegios del servidor web. En laboratorio, la carpeta existe solo unos segundos antes de que WordPress la limpie, así que una sola petición rara vez basta: hace falta sondeo automatizado.
Gravedad: ¿8,1 o baja?
- Wordfence, que asignó el CVE, lo califica con CVSS 8,1 (alto); la complejidad de ataque es alta por la ventana de tiempo requerida.
- El aviso de seguridad propio de WordPress en GitHub (GHSA-4w3m-c66w-69mg) lo etiqueta como baja.
- La diferencia importa menos que el hecho de que ya hay explotación: no es teoría.
Explotación en curso
Según lo reportado por The Hacker News con datos de Wordfence, el primer intento bloqueado llegó nueve minutos después de desplegar la regla de firewall. En las primeras 21 horas se registraron más de 18.500 solicitudes dirigidas a rutas del instalador en wp-content/upgrade, y en 24 horas se bloquearon 62.969 ataques. Algunas fuentes sondeaban los mismos grupos pequeños de sitios durante unas 14,5 horas, esperando el instante en que se ejecutara una actualización.
Condiciones para que funcione
- Una actualización de núcleo con paquete completo (que incluye los archivos del instalador).
- Acceso web y ejecución de PHP en
wp-content/upgrade. - Una ruta de preparación que el atacante pueda predecir o descubrir.
- Tiempo suficiente antes de que se eliminen los archivos temporales.
Versiones corregidas
- Rama 7.1: 7.1.4 (última vulnerable 7.1.3)
- Rama 7.0: 7.0.8
- Rama 6.9: 6.9.11
- Rama 6.8: 6.8.12
- Rama 4.7: 4.7.39
Las ramas 4.6 y anteriores no reciben parche. Confirme en Escritorio → Actualizaciones la versión exacta que reporta cada sitio en lugar de asumir que la actualización automática en segundo plano ya se aplicó.
Qué hacer hoy
- Actualice a 7.1.4 o al backport de su rama.
- Si aún no puede, bloquee el acceso web a
wp-content/upgrade/antes de actualizar. WordPress lee y escribe esa carpeta por el sistema de archivos, así que bloquearla por HTTP no rompe nada. En nginx:location ^~ /wp-content/upgrade/ { deny all; }. En Apache:Require all denieddentro de un.htaccessen esa carpeta. - Revise los registros de acceso desde el 28 de octubre buscando peticiones a
/wp-content/upgrade/y asetup-config.php. - Si usa Wordfence, active el modo de protección extendida, que se ejecuta antes de que cargue WordPress.
- Migre cualquier sitio en rama 4.6 o anterior a una versión soportada.
Otras correcciones de la versión
La mayoría de los otros 21 problemas requieren una cuenta de Colaborador, Autor o Editor: XSS almacenado en varios bloques, fallos en la API de Interactividad, divulgación de borradores del Personalizador y un fallo de permisos en roles que moderan comentarios. También se actualizaron los certificados raíz tras la revocación de eMudhra. Todo justifica actualizar igualmente.
Nuestra lectura
Lo llamativo es la ironía: el momento vulnerable es la propia actualización. Para quienes administran muchos sitios con actualizaciones automáticas, el riesgo es real porque los atacantes esperan esa ventana. Parchear rápido y cerrar la carpeta temporal son medidas baratas que cortan el ataque de raíz.