Lo esencial
La agencia estadounidense de ciberseguridad CISA confirmó el 3 de noviembre de 2026 que atacantes están explotando en el mundo real una vulnerabilidad grave del núcleo de WordPress, registrada como CVE-2026-119977. La ha incluido en su catálogo de vulnerabilidades explotadas conocidas (KEV) y ha ordenado a las agencias federales civiles parchear antes del 6 de noviembre. Si gestionas cualquier web en WordPress, esto te afecta directamente.
Qué es la vulnerabilidad
Se trata de una condición de carrera del tipo TOCTOU (time-of-check, time-of-use) en el mecanismo de actualización del núcleo de WordPress, descubierta por el investigador Umut Bayram (Picus Security).
En la práctica: durante las actualizaciones completas del núcleo, WordPress usa rutas de staging predecibles y accesibles desde la web. Un atacante remoto sin autenticación puede aprovechar la ventana de tiempo entre la comprobación de un archivo y su uso para ejecutar código en el servidor. La explotación se considera de complejidad alta, pero eso no ha frenado a los atacantes: la automatización hace el resto.
- Versiones afectadas: WordPress Core 4.7 a 7.1.3
- Versión que corrige: WordPress 7.1.4 (publicada el 28 de octubre de 2026)
- Severidad: CVSS 8.1 (alta)
La explotación ya está en marcha
La empresa de seguridad Wordfence informó de que bloqueó 13.095 ataques dirigidos a esta vulnerabilidad en 24 horas. Es una cifra que muestra el interés de los atacantes, aunque conviene matizarla: intentos bloqueados no equivalen a webs comprometidas. CISA, por su parte, no ha publicado cifras de sistemas comprometidos ni atribución sobre quién está detrás de la campaña.
El patrón, sin embargo, es conocido y debería preocuparte: en julio, el equipo de seguridad de WordPress parcheó la cadena crítica wp2shell (CVE-2026-63030 y CVE-2026-60137). Los exploits públicos aparecieron un día después de los parches y en pocos días los atacantes ya estaban comprometiendo servidores sin actualizar, desplegando webshells persistentes. En septiembre, un actor de habla china usó esa misma cadena para robar más de 18.500 registros de pequeñas empresas y organismos públicos. La lección: con WordPress, la ventana entre parche y explotación se mide en días, no en semanas.
Qué hacer ahora mismo
- Actualiza a WordPress 7.1.4 (o superior) en todas tus instalaciones. Hoy, no la semana que viene.
- Inventaría todas tus webs: incluye las olvidadas, las de staging y las alojadas en proveedores externos.
- Revisa los logs del servidor buscando peticiones sospechosas a rutas de staging o relacionadas con el proceso de actualización.
- Busca señales de compromiso: ficheros PHP inesperados, componentes del núcleo modificados, plugins que no instalaste tú.
- Si hubo compromiso, el parche no basta: hay que limpiar webshells y plugins maliciosos, y rotar contraseñas de administración, credenciales de base de datos y claves API.
- Endurece el perímetro: restringe el acceso a /wp-admin, usa WAF y mantén plugins y temas al día; son la vía de entrada alternativa más común.
Mirada Blue Team: qué vigilaría un SOC
Más allá del parcheo, esto es lo que un equipo SOC debería estar monitorizando estos días:
- Peticiones HTTP a rutas de staging o instaladores de WordPress fuera de ventanas de mantenimiento programadas.
- Aparición de ficheros
.phpnuevos o modificados en el núcleo, y plugins que nadie del equipo reconoce. - Picos de tráfico automatizado contra rutas de actualización: el escaneo masivo precede a la explotación dirigida.
- Conexiones salientes inusuales desde el servidor web (posible beacon de webshell).
Y una reflexión: esta vulnerabilidad convierte una operación rutinaria y «segura» —actualizar el CMS— en superficie de ataque. Los mecanismos de actualización merecen el mismo escrutinio que cualquier otro componente expuesto.
Nota personal
Esta misma web, bryanacanda.com, corre sobre WordPress 7.1.4: ya está parcheada contra CVE-2026-119977. Predicar con el ejemplo también es Blue Team.