Durante años, la recomendación básica de seguridad en WordPress ha sido la misma: mantener el sitio actualizado. Esa regla sigue vigente, pero una vulnerabilidad confirmada esta semana muestra que el momento de actualizar también puede ser el momento del ataque. La Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) incorporó el 3 de noviembre la falla CVE-2026-119977 de WordPress a su catálogo de vulnerabilidades explotadas activamente, lo que significa que ya hay atacantes usándola contra sitios reales.
Para municipalidades, universidades, gobiernos regionales y empresas que publican su portal en WordPress, el aviso tiene una lectura directa: el riesgo no está solo en no actualizar, sino en cómo se actualiza.
Qué es la vulnerabilidad y por qué es distinta
La falla es una condición de carrera, un tipo de error en el que el sistema revisa algo en un momento y lo usa un instante después, dejando un espacio que un tercero puede aprovechar. En este caso, el espacio aparece mientras WordPress instala una actualización completa de su núcleo.
Según CISA, el problema se debe a que, durante ese proceso, WordPress deja archivos temporales en rutas predecibles y accesibles desde internet. Entre ellos está el instalador del sitio. Un atacante que logre llegar a esas rutas justo en esa ventana puede terminar ejecutando código en el servidor, es decir, tomar el control del sitio y, potencialmente, de lo que esté alojado junto a él.
Dos detalles hacen que esta falla sea especialmente delicada. El primero es que no requiere tener una cuenta en el sitio: cualquier visitante anónimo puede intentarlo. El segundo es que el ataque depende de sincronización, no de engañar a nadie, así que no hay correo de phishing que detectar ni usuario que capacitar.
Una falla calificada como "baja" que terminó en el catálogo de CISA
El caso tiene un matiz que vale la pena conocer. En su aviso del 29 de octubre, WordPress clasificó la falla con severidad baja. Wordfence, la firma que asignó el identificador, la evaluó en cambio con 8.1 sobre 10 en la escala CVSS, es decir, severidad alta. La diferencia se explica porque explotarla exige acertar con una ventana de tiempo corta, lo que en teoría la hace difícil.
Los ataques empezaron en cuestión de horas
En la práctica, esa dificultad no detuvo a nadie. Wordfence registró más de 18 500 solicitudes dirigidas a las rutas temporales del instalador en las primeras 21 horas después de que se hizo pública la falla, y bloqueó 12 632 intentos de ataque en un solo día. Los atacantes no necesitan saber cuándo actualiza un sitio concreto: les basta con consultar esas rutas de forma automatizada contra miles de sitios y esperar a coincidir con alguno.
La lección para cualquier área de TI es clara: una calificación de severidad baja no equivale a un riesgo bajo cuando la falla es fácil de automatizar.
Qué versiones están afectadas
El aviso de seguridad de WordPress cubre una franja muy amplia de versiones, desde la 4.7 hasta la 7.1.3. Las versiones corregidas son:
- 7.1.4, publicada el 28 de octubre de 2026, para quienes están en la rama más reciente.
- 7.0.8 para la rama 7.0, y versiones equivalentes en cada rama anterior hasta la 4.7 (por ejemplo, 4.9.35, 4.8.34 y 4.7.39).
- 4.6 y anteriores no tienen corrección. WordPress ya no publica actualizaciones de seguridad para esas versiones, por lo que la única salida es migrar.
Este último punto importa en el sector público peruano, donde no es raro encontrar portales de gerencias, proyectos o eventos que se montaron hace años y nadie volvió a tocar.
El dilema: actualizar es obligatorio, pero hay que hacerlo con control
La respuesta no es dejar de actualizar. Es convertir la actualización en un procedimiento controlado, no en un clic automático a cualquier hora. En la práctica, eso implica:
- Inventariar todos los sitios WordPress de la institución, incluidos subdominios, portales de prueba y micrositios temporales, y registrar qué versión tiene cada uno.
- Programar las actualizaciones en ventanas de mantenimiento definidas, con el sitio en modo mantenimiento o con acceso restringido mientras dura el proceso.
- Filtrar el tráfico antes de que llegue al servidor con un Web Application Firewall capaz de bloquear peticiones a rutas de instalación y archivos temporales, que es exactamente lo que buscan los atacantes en esta campaña.
- Revisar los registros del servidor después de cada actualización, buscando solicitudes al instalador en rutas inusuales.
- Verificar la integridad del sitio tras actualizar y contar con respaldos recientes y probados por si hay que restaurar.
Conviene recordar algo que ya comentamos al hablar de los ataques a portales web en el Perú: un filtro de este tipo protege según las reglas que alguien mantenga al día, no por el solo hecho de estar instalado.
Qué está en juego para las entidades públicas
Un portal institucional comprometido no es solo un problema de imagen. Desde un servidor tomado, un atacante puede alterar comunicados oficiales, insertar enlaces maliciosos dirigidos a los ciudadanos, usar el sitio para alojar páginas de phishing con un dominio de confianza o moverse hacia otros sistemas de la red.
Si el sitio recoge datos personales, como formularios de trámites, mesas de partes virtuales o inscripciones, el incidente entra además en el terreno de la Ley 29733 de Protección de Datos Personales. La entidad responde por las medidas de seguridad que aplicó para proteger esa información, y una vulnerabilidad conocida, con parche disponible y explotación confirmada, es difícil de justificar ante la Autoridad Nacional de Protección de Datos Personales.
Más allá del parche: la capacidad de reacción
Este caso ilustra un problema recurrente: entre la publicación de un parche y su instalación en todos los sitios de una organización pasan días o semanas, y los atacantes empiezan a buscar víctimas en cuestión de horas. Cerrar esa brecha no depende solo de tener herramientas, sino de tener a alguien que vigile los avisos de seguridad, priorice qué corregir primero y verifique que la corrección se aplicó. Eso es justamente lo que ordena una estrategia de gestión de vulnerabilidades.
Para muchas instituciones con equipos de TI reducidos, esa vigilancia es difícil de sostener. Por eso conviene combinar la protección del sitio con una protección de endpoints en los servidores y equipos de la red, de modo que, si un atacante logra entrar por el portal, encuentre obstáculos para avanzar.
Conclusión
La indicación de siempre, "mantenga su WordPress actualizado", sigue siendo correcta. Lo que cambia con esta falla es que el propio proceso de actualización abre una rendija, y que hay atacantes revisando miles de sitios de forma automática para encontrar a alguien justo en ese instante.
No es motivo para postergar el parche, sino para dejar de actualizar a ciegas: saber cuántos WordPress tiene la institución, en qué versión está cada uno, actualizarlos en una ventana controlada y mirar los registros después. Un sitio olvidado en la versión 4.6, sin corrección posible, es hoy el eslabón más expuesto de cualquier entidad.
