Una vulnerabilidad de WordPress ya explotada por ciberdelincuentes puede seguir poniendo en peligro las páginas web durante la instalación del parche de seguridad. El fallo CVE-2026-119977 afecta a versiones desde la 4.7 hasta la 7.1.3 y permite, en determinadas circunstancias, ejecutar código malicioso en el servidor.
Actualizar WordPress para corregir un fallo de seguridad puede convertirse, paradójicamente, en el último momento de exposición de una página web. Una investigación del especialista Umut Bayram, de Picus Security, ha revelado que determinados sitios pueden seguir siendo vulnerables durante los segundos que tarda en instalarse el parche destinado a protegerlos.
La vulnerabilidad, identificada como CVE-2026-119977, afecta a versiones de WordPress comprendidas entre la 4.7 y la 7.1.3. El problema está relacionado con el sistema de actualización del gestor de contenidos, que puede almacenar temporalmente archivos de instalación en una carpeta accesible desde internet.
Un atacante que consiga localizar esa carpeta y acceder a determinados componentes antes de que finalice la actualización podría ejecutar código PHP en el servidor.
La situación ha adquirido especial relevancia porque la Agencia de Seguridad de Infraestructuras y Ciberseguridad de Estados Unidos (CISA) ha incorporado la vulnerabilidad a su catálogo de fallos explotados activamente.
WordPress ha publicado una corrección en la versión 7.1.4, además de actualizaciones de seguridad para ramas anteriores compatibles.
Sin embargo, el investigador advierte de una circunstancia importante: el proceso que instala la actualización todavía utiliza parte del código vulnerable de la versión antigua.
Por tanto, algunos sitios pueden quedar expuestos durante un breve intervalo antes de completar la protección.
La recomendación principal es bloquear el acceso público a la carpeta wp-content/upgrade antes de actualizar WordPress, sin impedir que el propio sistema siga utilizando ese directorio internamente.
Qué es la vulnerabilidad CVE-2026-119977 de WordPress
La vulnerabilidad CVE-2026-119977 afecta al mecanismo que WordPress utiliza para instalar determinadas actualizaciones de su núcleo.
Cuando el sistema descarga una nueva versión, puede descomprimir temporalmente sus archivos en una carpeta situada dentro del directorio wp-content/upgrade.
En condiciones normales, estos archivos deberían utilizarse únicamente durante la actualización y desaparecer después de completar el proceso.
El problema aparece porque esa copia temporal puede incluir componentes del instalador de WordPress.
Si el servidor permite acceder a ellos desde internet, un atacante podría intentar utilizarlos antes de que sean eliminados.
La explotación requiere determinadas condiciones, entre ellas que el atacante pueda identificar el directorio temporal y acceder a los archivos pertinentes durante el breve intervalo en que están disponibles.
No se trata de una vulnerabilidad que permita comprometer automáticamente cualquier instalación de WordPress en cualquier momento.
El riesgo depende de la versión instalada, del tipo de actualización, de la configuración del servidor y de la accesibilidad de los archivos temporales.
Aun así, su gravedad es considerable porque puede permitir la ejecución de código sin disponer previamente de una cuenta de usuario.
Por qué instalar el parche puede dejar WordPress expuesto una última vez
El aspecto más llamativo del hallazgo es que el parche no elimina inmediatamente todos los riesgos durante su propia instalación.
La explicación está en el funcionamiento del actualizador.
Para instalar la versión corregida, WordPress comienza ejecutando el mecanismo de actualización que ya existe en el sitio.
Si ese mecanismo pertenece a una versión vulnerable, puede seguir creando directorios temporales con nombres previsibles.
La nueva versión incorpora una modificación para generar nombres aleatorios, dificultando que un atacante localice esos archivos.
Sin embargo, esa protección comienza a funcionar plenamente una vez que el código corregido ha sustituido al anterior.
Durante el proceso de instalación todavía puede existir una oportunidad de ataque.
El investigador Umut Bayram señala que, si un ciberdelincuente consigue acceder al instalador temporal, podría configurar esa copia provisional de WordPress con una base de datos bajo su control.
Después podría autenticarse en esa instalación temporal y ejecutar código PHP con los permisos del servidor web.
Desde ese entorno, dependiendo de los permisos disponibles, podría leer o modificar archivos de la instalación principal.
El riesgo se concentra en un intervalo breve, pero potencialmente suficiente para un atacante que esté vigilando el proceso de actualización.
WordPress 7.1.4 corrige el fallo, pero hay que actualizar con precaución
WordPress publicó la corrección de seguridad en la versión 7.1.4.
También distribuyó actualizaciones equivalentes para ramas anteriores que todavía reciben mantenimiento.
La solución introduce cambios en el tratamiento de los archivos temporales.
En particular, el sistema deja de utilizar nombres previsibles para determinados directorios empleados durante la actualización.
Además, incorpora medidas para impedir que un archivo de configuración generado dentro de una instalación temporal sustituya al archivo principal del sitio.
Estas modificaciones reducen las posibilidades de explotación una vez instalado el parche.
No obstante, la investigación advierte de que la actualización debe realizarse con medidas de protección adicionales cuando el sitio todavía ejecuta una versión vulnerable.
Esto no significa que los administradores deban evitar actualizar.
Al contrario: mantener una instalación vulnerable aumenta la exposición a ataques.
La recomendación consiste en proteger previamente el directorio temporal y aplicar después la corrección oficial.
CISA confirma que la vulnerabilidad está siendo explotada
La incorporación de CVE-2026-119977 al catálogo de vulnerabilidades explotadas conocidas de CISA constituye una señal relevante.
Este registro reúne fallos para los que existe evidencia de explotación real.
La agencia estadounidense incorporó la vulnerabilidad durante la primera semana de noviembre de 2026.
Sin embargo, no publicó detalles específicos sobre los ataques utilizados para justificar su inclusión.
Por su parte, la empresa de seguridad Wordfence detectó intentos de ataque apenas nueve minutos después de desplegar una regla de protección contra la vulnerabilidad.
Según su análisis, algunas de las fuentes más activas continuaron examinando pequeños grupos de páginas web durante aproximadamente 14,5 horas.
Ese comportamiento resulta compatible con intentos de detectar el momento en que los sitios realizan una actualización.
No obstante, la observación de intentos de ataque no demuestra que todos ellos consiguieran comprometer los servidores.
La vulnerabilidad recibió una puntuación de 8,1 sobre 10 en la escala CVSS, según la valoración recogida en el registro CVE por Wordfence.
La puntuación refleja un riesgo de seguridad elevado, aunque WordPress valoró el fallo con una severidad inferior en su propio aviso.
Qué versiones de WordPress están afectadas
La investigación identifica como vulnerables las versiones de WordPress desde la 4.7 hasta la 7.1.3.
La situación concreta depende del tipo de actualización y del comportamiento del código instalado.
En versiones de WordPress 5.9 y posteriores, el mecanismo vulnerable puede crear carpetas temporales con nombres derivados del archivo descargado.
Esto facilita que un atacante pueda predecir dónde aparecerá la copia provisional.
En versiones comprendidas entre la 4.4 y la 5.8, el sistema añade caracteres aleatorios al nombre de la carpeta.
Ese comportamiento dificulta la localización del directorio, aunque no elimina necesariamente el riesgo si su ubicación se revela por otros medios.
Las versiones 4.6 y anteriores ya no reciben actualizaciones de seguridad.
Por tanto, los administradores que todavía utilizan instalaciones tan antiguas deberían planificar su migración a una versión compatible.
Una instalación sin mantenimiento no puede considerarse protegida simplemente porque no haya presentado incidentes visibles.
No todas las actualizaciones presentan el mismo riesgo
Uno de los aspectos técnicos más importantes es la diferencia entre los paquetes de actualización completos y parciales.
Un paquete completo incluye los archivos necesarios para instalar WordPress.
Por ello, puede incorporar componentes del instalador que resultan relevantes para la vulnerabilidad.
En cambio, una actualización parcial contiene únicamente los archivos modificados entre determinadas versiones.
Si esos archivos no incluyen los componentes necesarios para ejecutar el instalador, la exposición descrita no se produce de la misma manera.
The Hacker News comprobó que algunas actualizaciones dentro de una misma rama, como el paso de WordPress 7.1.3 a 7.1.4, podían ofrecerse mediante paquetes parciales.
Por el contrario, determinados saltos entre ramas utilizaban paquetes completos.
Sin embargo, una instalación puede recibir un paquete completo incluso cuando existe uno parcial, por ejemplo, si los archivos del núcleo han sido modificados o se está realizando una reinstalación.
La diferencia entre actualización completa y parcial influye en la exposición, pero no sustituye la necesidad de proteger el directorio temporal.
La medida preventiva recomendada resulta útil con independencia del paquete finalmente seleccionado.
Cómo proteger WordPress antes de instalar la actualización de seguridad
La recomendación de Umut Bayram, investigador de Picus Security, consiste en impedir que los visitantes externos puedan acceder al directorio temporal utilizado durante las actualizaciones.
La carpeta afectada es:
wp-content/upgrade
WordPress necesita utilizarla para descomprimir archivos, pero eso no significa que deba estar disponible públicamente desde un navegador.
El objetivo es permitir que el gestor de contenidos siga trabajando con ella desde el servidor, mientras se bloquean las solicitudes HTTP externas.
Para los administradores de WordPress, el procedimiento recomendado es el siguiente:
- Realizar una copia de seguridad de los archivos y la base de datos antes de introducir cambios.
- Bloquear el acceso web a
wp-content/upgrademediante la configuración de Apache, Nginx o las herramientas del proveedor de alojamiento. - Comprobar que el directorio devuelve un error HTTP 403, que indica que el acceso está prohibido.
- Instalar WordPress 7.1.4 o la actualización de seguridad correspondiente a la rama utilizada.
- Verificar el funcionamiento del sitio después de actualizar y revisar los registros de seguridad.
Estas operaciones deben realizarse con precaución, especialmente en páginas empresariales, tiendas online y sitios con mucho tráfico.
Una configuración incorrecta del servidor puede provocar interrupciones del servicio.
Por ello, los administradores sin experiencia deberían solicitar ayuda a su proveedor de alojamiento o a un profesional especializado.
Cómo bloquear el acceso a la carpeta vulnerable en Apache y Nginx
La investigación recoge distintas opciones de protección en función del servidor utilizado.
En instalaciones con Nginx, el administrador puede incorporar una regla que deniegue las solicitudes dirigidas al directorio de actualizaciones:
location ^~ /wp-content/upgrade/ {
deny all;
}Esta configuración debe añadirse en el contexto adecuado del servidor y aplicarse después de comprobar que la sintaxis es correcta.
En servidores Apache, puede establecerse una restricción de acceso mediante una directiva Directory dentro de la configuración del sitio:
<Directory "/ruta/real/wordpress/wp-content/upgrade">
Require all denied
</Directory>La ruta debe sustituirse por la ubicación real de WordPress en el servidor.
Si el administrador solo dispone de acceso al archivo .htaccess, el investigador propone incorporar la siguiente regla en el archivo situado en la raíz de WordPress, antes de las reglas habituales de reescritura:
RedirectMatch 403 ^/wp-content/upgrade/No se recomienda colocar el archivo .htaccess de protección dentro de la propia carpeta wp-content/upgrade.
La razón es que el actualizador vulnerable puede eliminar el contenido de ese directorio antes de comenzar a descomprimir los archivos.
Si la protección se encuentra dentro de la carpeta, podría desaparecer precisamente cuando resulta necesaria.
La configuración debe probarse antes de iniciar la actualización.
Actualizar manualmente WordPress puede evitar la exposición temporal
El investigador también plantea una alternativa para administradores con conocimientos técnicos: realizar la actualización manualmente fuera del directorio público del servidor.
Este procedimiento evita que se genere una copia temporal del instalador en una ubicación accesible desde internet.
La operación requiere descargar la versión oficial, descomprimirla en una carpeta no pública y sustituir los archivos correspondientes del núcleo de WordPress.
Es imprescindible preservar el archivo de configuración wp-config.php y el directorio wp-content, que contiene elementos fundamentales del sitio, como temas, plugins y archivos multimedia.
También deben realizarse copias de seguridad y completarse las actualizaciones de la base de datos cuando corresponda.
La actualización manual puede reducir la exposición descrita, pero exige conocimientos suficientes para evitar pérdidas de información o interrupciones del servicio.
El investigador advierte además de que utilizar el comando habitual de actualización de WP-CLI no elimina automáticamente el problema.
La razón es que dicho comando emplea el mecanismo de actualización de WordPress y puede recurrir al mismo directorio temporal.
Por tanto, ejecutar la actualización desde una terminal no garantiza por sí solo que desaparezca la ventana de exposición.
Cómo saber si una página WordPress ha sufrido un ataque
La vulnerabilidad está siendo explotada, pero eso no significa que todos los sitios afectados hayan sido comprometidos.
Los administradores deberían revisar determinados indicadores que pueden revelar intentos de acceso o modificaciones no autorizadas.
Wordfence recomienda prestar especial atención a:
- Solicitudes inesperadas a archivos PHP dentro de
wp-content/upgrade. - Cuentas de administrador desconocidas que hayan aparecido sin autorización.
- Plugins que nadie reconoce haber instalado.
- Archivos PHP sospechosos dentro del directorio temporal de actualizaciones.
También resulta conveniente examinar los registros del servidor, los cambios recientes en archivos y las alertas del sistema de seguridad.
La aparición de uno de estos indicadores no demuestra automáticamente que se haya explotado esta vulnerabilidad concreta.
Sin embargo, puede justificar una investigación más profunda.
Si existen indicios de compromiso, actualizar WordPress no basta para garantizar que el sitio vuelva a estar limpio.
Un atacante podría haber introducido archivos maliciosos o creado mecanismos de acceso persistente.
En esos casos, es recomendable realizar un análisis de seguridad completo y revisar las credenciales administrativas.
Por qué esta vulnerabilidad preocupa especialmente a las empresas
WordPress es una de las plataformas más utilizadas para publicar contenidos en internet.
Su presencia en páginas corporativas, periódicos digitales, comercios electrónicos y sitios institucionales convierte cualquier vulnerabilidad del núcleo en un asunto relevante para la ciberseguridad.
Un ataque que permita ejecutar código en el servidor podría tener consecuencias importantes.
Dependiendo de los permisos disponibles, un ciberdelincuente podría intentar modificar archivos, introducir código malicioso, alterar el funcionamiento de la web o acceder a información almacenada.
En un comercio electrónico, una intrusión podría comprometer procesos de compra o información comercial.
En un medio digital, podría permitir la modificación no autorizada de contenidos o la interrupción de la publicación.
En una web corporativa, podría afectar a la disponibilidad del servicio y a la confianza de los clientes.
Estas consecuencias son escenarios posibles, no daños confirmados en todos los sitios afectados por CVE-2026-119977.
La gravedad real dependerá de la configuración del servidor y de las medidas de protección existentes.
El peligro de confiar únicamente en las actualizaciones automáticas
Las actualizaciones automáticas constituyen una herramienta importante para mantener WordPress protegido.
Permiten instalar correcciones sin que el administrador tenga que intervenir manualmente en cada ocasión.
Sin embargo, esta investigación demuestra que automatizar la instalación de un parche no garantiza que el proceso carezca de riesgos.
Cuando una instalación utiliza código vulnerable para descargar y descomprimir la versión corregida, puede existir una exposición temporal.
El problema no significa que deban desactivarse las actualizaciones automáticas de forma generalizada.
De hecho, retrasar la instalación de parches puede prolongar la exposición frente a vulnerabilidades conocidas.
La solución más razonable consiste en combinar las actualizaciones con medidas preventivas permanentes, como restringir el acceso público a directorios internos que no necesitan estar disponibles desde internet.
También es importante mantener copias de seguridad, revisar los permisos del servidor y supervisar los registros de actividad.
La seguridad de WordPress no depende de una única herramienta.
La vulnerabilidad recibe una puntuación de 8,1 sobre 10
La vulnerabilidad CVE-2026-119977 ha recibido una puntuación de 8,1 sobre 10 en la escala CVSS, según la valoración de Wordfence recogida en el registro CVE.
La escala CVSS permite expresar la gravedad técnica de una vulnerabilidad mediante criterios estandarizados.
Una puntuación de 8,1 se sitúa dentro del rango de gravedad alta.
Sin embargo, las valoraciones pueden variar entre organizaciones según los factores considerados.
El aviso de seguridad de WordPress asignó al problema una severidad inferior.
La diferencia refleja que el riesgo está condicionado por circunstancias específicas, como la accesibilidad del directorio temporal y la necesidad de aprovechar un intervalo muy breve.
Según las pruebas de laboratorio mencionadas por The Hacker News, esa ventana de oportunidad podía durar apenas unos segundos.
Un intervalo reducido no equivale a ausencia de riesgo, especialmente cuando existen herramientas capaces de automatizar solicitudes y detectar cambios en servidores.
Qué deben hacer los propietarios de páginas WordPress en España
La alerta también resulta relevante para empresas, autónomos y medios digitales españoles que utilizan WordPress.
La ubicación geográfica del servidor no elimina la vulnerabilidad.
Cualquier instalación afectada que reúna las condiciones necesarias podría convertirse en objetivo de intentos de explotación.
Por ello, los responsables de sitios web deberían comprobar la versión instalada y revisar cómo se gestionan las actualizaciones.
Las páginas que utilizan alojamiento administrado pueden consultar a su proveedor si el directorio temporal está protegido frente a accesos externos.
Los sitios con servidores propios deberían verificar directamente la configuración de Apache o Nginx.
Además, resulta recomendable comprobar que existen copias de seguridad recientes y que los mecanismos de recuperación funcionan correctamente.
La prioridad es aplicar la actualización de seguridad sin dejar expuesto el directorio temporal durante el proceso.
No conviene posponer indefinidamente el parche por temor a la vulnerabilidad.
La existencia de ataques activos refuerza la necesidad de actuar con rapidez, pero siguiendo un procedimiento seguro.
WordPress afronta un problema que demuestra la complejidad de la ciberseguridad
La investigación de Picus Security pone de manifiesto una situación poco habitual: el propio proceso de instalación de una corrección puede conservar temporalmente las condiciones que permiten explotar el fallo original.
WordPress ha desarrollado un parche para solucionar la vulnerabilidad.
Sin embargo, determinadas instalaciones todavía necesitan ejecutar el código antiguo para aplicar esa corrección.
Esta circunstancia crea una ventana de exposición que los administradores deben tener en cuenta.
El caso también demuestra que una actualización de seguridad no debe evaluarse únicamente por el resultado final, sino por las operaciones que realiza durante su instalación.
La existencia de intentos de explotación y la inclusión del fallo en el catálogo de CISA convierten la situación en una advertencia relevante para quienes administran sitios web.
La conclusión práctica es clara: los propietarios de páginas WordPress deben proteger el acceso a wp-content/upgrade, instalar la versión corregida y revisar posibles indicios de actividad maliciosa.
La actualización sigue siendo necesaria. Lo que cambia es la importancia de preparar correctamente el servidor antes de ejecutarla.
Chollones
Chollones
Chollones