✨︎ Resumen (TL;DR):
- WordPress 7.1.4 corrige la vulnerabilidad CVE-2026-119977, pero la primera instalación puede iniciar con el actualizador vulnerable.
- Wordfence bloqueó más de 240,000 intentos de explotación desde la divulgación; esa cifra no equivale a sitios comprometidos.
- Bloquea el acceso público a
wp-content/upgradeantes de actualizar y confirma la versión corregida de tu rama.
WordPress corrigió una vulnerabilidad que ya está siendo explotada, CVE-2026-119977, con la versión 7.1.4, publicada el 28 de octubre de 2026, pero la primera actualización todavía puede dejar expuestos a ciertos sitios. El actualizador vulnerable que ya está instalado puede crear archivos temporales accesibles desde internet durante el proceso; si un atacante llega a ellos en el momento preciso, podría ejecutar código en el servidor sin tener una cuenta. Wordfence recomienda bloquear antes la carpeta wp-content/upgrade, aplicar la corrección sin demora y comprobar después que el sitio quedó en una versión corregida.
CVE-2026-119977 es una vulnerabilidad del proceso de actualización del núcleo de WordPress que puede permitir la ejecución de código en el servidor si un atacante alcanza ciertos archivos temporales durante la instalación. El ataque no requiere una cuenta previa, pero tampoco deja una exposición permanente: depende de las condiciones del sitio y de que la intrusión coincida con la breve ventana de actualización.
Umut Bayram, investigador de Picus Security, reportó la falla. WordPress también adaptó la corrección para ramas antiguas hasta la 4.7. El aviso de seguridad enumera las versiones afectadas y corregidas de cada rama, mientras el proyecto recuerda que solo la versión más reciente recibe soporte activo.
El primer parche puede usar el actualizador viejo
Cuando WordPress instala un paquete completo, descomprime una copia temporal de sus archivos. Si esa copia incluye el instalador y el servidor permite acceder a él desde internet, el instalador puede quedar disponible mientras dura el proceso.
El parche cambia la forma de crear el directorio temporal. Sin embargo, para llegar a ese directorio desde una instalación vulnerable, la corrección pasa primero por el actualizador que ya estaba instalado. Bayram explicó a The Hacker News que esto puede dejar expuestos algunos sitios una vez más durante la instalación de la corrección.
Parte del arreglo ya impide que un archivo de configuración temporal sustituya al archivo de configuración del sitio durante esa primera actualización. Aun así, una copia temporal accesible podría permitir la ejecución de código antes de que el sistema la elimine.
Las condiciones cambian según el tipo de paquete:
- Paquete completo: incluye el instalador y WordPress lo descomprime en una copia temporal, que puede quedar expuesta si el servidor permite el acceso.
- Paquete parcial: contiene únicamente los archivos que cambiaron y solo presenta el escenario si incluye los archivos necesarios.
- Uso de un paquete completo: WordPress puede recurrir a él si los archivos del núcleo no coinciden con las comprobaciones oficiales o si se reinstala el sistema.
Las actualizaciones automáticas también pasan por el actualizador del sitio. Una vez instalada la versión corregida de la rama correspondiente, las actualizaciones posteriores utilizan el mecanismo corregido.
Bloquea wp-content/upgrade antes de actualizar
Bayram recomienda impedir desde el servidor web el acceso público a wp-content/upgrade antes de instalar la corrección. WordPress utiliza esa carpeta en el disco durante el proceso, por lo que la medida busca que sus archivos temporales no queden disponibles desde internet.
La configuración concreta depende del servidor. Colocar el archivo de restricción dentro de la propia carpeta temporal no resuelve el problema: el actualizador antiguo limpia su contenido antes de descomprimir los archivos. El investigador también describió una actualización manual fuera de la raíz pública del servidor como alternativa.
Wordfence aconseja comprobar que el sitio terminó en la versión corregida de su rama:
- Rama 7.1: 7.1.4.
- Rama 7.0: 7.0.8.
- Rama 6.9: 6.9.11.
Las instalaciones más antiguas deben consultar el aviso de seguridad para identificar la versión corregida de su rama. Las versiones 4.6 y anteriores no recibieron este parche; Bayram recomienda migrar a una versión con soporte.
Wordfence entregó una regla de protección a los usuarios de Premium, Care y Response el 28 de octubre y prevé ofrecerla a los usuarios de la versión gratuita el 27 de noviembre. Para que su firewall inspeccione las solicitudes a esos archivos temporales, debe estar optimizado y operar en modo Extended Protection.
Los intentos bloqueados no son sitios comprometidos
En su informe publicado el 5 de noviembre, Wordfence reportó más de 240,000 intentos de explotación bloqueados por su firewall desde la divulgación. El 30 de octubre se concentraron más de 74,000. La firma indicó que muchas solicitudes probablemente fueron automatizadas para coincidir con el breve periodo de actualización.
El recuento mide intentos que Wordfence bloqueó, no 240,000 sitios comprometidos. La empresa recomienda revisar los registros del servidor y buscar cuentas de administrador, plugins o archivos inesperados. No encontrar esas señales tampoco garantiza que no haya existido una intrusión.
La Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos, CISA, incorporó la falla a su catálogo de vulnerabilidades explotadas el 3 de noviembre. Su ficha fijó el 6 de noviembre como fecha de remediación para las agencias civiles federales sujetas a su directiva y exige una revisión forense. Ese plazo no es una obligación general para todos los sitios de WordPress.
Wordfence asignó a la vulnerabilidad una puntuación de 8.1 sobre 10, considerada alta en la escala CVSS. El equipo de WordPress la clasifica como baja. Ambas fuentes coinciden en que el ataque depende de una ventana breve durante la actualización, aunque sus fichas no explican la diferencia entre las dos clasificaciones.
Aplicar la versión corregida no reemplaza esas comprobaciones. Si el sitio pasó por la ventana de actualización antes de bloquear la carpeta, el administrador debe revisar los registros, las cuentas, los plugins y los archivos inesperados, además de confirmar la versión instalada.
