WordPress 7.1.4: vulnerabilidad crítica ya explotada

Actualizado el 06/11/2026: esta nota se enfoca en lo que cambió desde que CISA sumó CVE-2026-119977 a su catálogo KEV y en las otras 21 correcciones de WordPress 7.1.4 que casi nadie está mirando. Si buscás el desglose completo del CVE y de la telemetría de ataques, ya lo cubrimos en detalle en nuestra cobertura inicial del CVE-2026-119977 y en el análisis de los números de Wordfence y GBHackers. Acá no vamos a repetir esas dos notas, vamos a sumar lo que falta.

En pocas palabras: CISA confirmó la explotación activa de CVE-2026-119977 (CVSS 8.1), una falla RCE sin autenticación en WordPress Core, y la agregó a su catálogo KEV el 3 de noviembre de 2026 con fecha límite federal el 6 de noviembre. El parche salió en 7.1.4 el 28 de octubre. Lo que todavía no analizamos a fondo: qué implica esa fecha límite para quien no es una agencia federal, y por qué el resto de las 22 vulnerabilidades que corrige 7.1.4 merece su propia revisión.

¿Qué significa que CVE-2026-119977 esté en el catálogo KEV de CISA?

El catálogo Known Exploited Vulnerabilities de CISA no es una lista de fallas peligrosas en teoría: es una lista de fallas que la agencia ya confirmó explotadas en el mundo real, con una fecha límite de remediación obligatoria para agencias civiles federales de EE.UU. bajo la directiva BOD 26-04. CVE-2026-119977 entró el 3 de noviembre de 2026, con impacto técnico calificado como total y fecha límite el 6 de noviembre. Ahora bien, ¿a quién le importa esa fecha si tu sitio no es una agencia federal? A nadie legalmente. Pero la lógica de priorización que usa BOD 26-04 —tratar como urgente lo que ya está siendo explotado, no lo que podría explotarse algún día— sirve igual para cualquier administrador. La pregunta útil no es «¿me obliga CISA?» sino «¿mi sitio cumple las condiciones que hacen que esto sea explotable hoy?».

Como criterio de decisión, tiene sentido tratar el 6 de noviembre como fecha propia si tu sitio cumple dos o más de estos puntos:

• Corre una versión por debajo del parche de su rama (7.1.3, 7.0.7, 6.9.10 o anterior).
• Tiene wp-content/upgrade/ accesible públicamente, que es el comportamiento por defecto en una instalación estándar.
• Actualiza el core en segundo plano sin que nadie revise después si la actualización realmente terminó.
• Maneja datos de clientes, pagos o cuentas de usuario, donde un compromiso sale más caro que una ventana de mantenimiento programada.

Si marcaste dos o más, no hace falta esperar a que una auditoría te lo señale.

Los números de explotación, en resumen

Wordfence midió más de 18.500 pedidos contra rutas de staging en las primeras 21 horas tras la publicación del CVE, y GBHackers elevó esa cifra a casi 59.000 intentos bloqueados en 24 horas. Ya desglosamos esos números, su procedencia y por qué «intento bloqueado» no equivale a «sitio comprometido» en esta nota dedicada a la telemetría de ataques. Lo único que vale la pena repetir acá es el matiz que suele perderse: esas cifras cuentan solicitudes, no ejecuciones exitosas, porque el ataque solo funciona si el pedido coincide con una ventana activa de actualización completa del core.

Las otras 21 correcciones: por qué conviene auditar los roles Contributor

Acá está lo que de verdad no se cubrió todavía en profundidad. WordPress 7.1.4 corrige 22 vulnerabilidades repartidas en 17 advisories, según el conteo que reporta el análisis técnico de hatamoto.dev, muy por encima de las 7 que había corregido la versión 7.1.3 tres semanas antes. El RCE sin login es la estrella mediática, pero es la única de las 22 que no requiere ninguna cuenta. Casi todo el resto arranca con un rol Contributor.

Siete advisories están ligados a la Interactivity API y comparten la misma causa raíz: KSES dejaba pasar atributos data-* con cualquier valor, y las directivas de la Interactivity API se escriben justamente como atributos data-*. Eso le permitía a un Contributor guardar una directiva en un post que el runtime del front-end después ejecutaba para cualquier visitante, sin que un administrador tuviera que aprobar nada específico de ese código. El parche ajusta KSES, el procesador PHP de directivas y el runtime.

Ejemplo hipotético (no corresponde a ningún caso reportado): pensemos en un sitio de membresías donde usuarios registrados publican reseñas de productos con rol Contributor, sin revisión editorial línea por línea antes de que el contenido se renderice en el front-end. Antes del parche, alguien con ese rol podría haber guardado una directiva data-* maliciosa dentro de una reseña, y el runtime de Interactivity API la habría ejecutado para cualquier visitante que viera esa página, sin necesitar jamás una cuenta de administrador. Este escenario sirve para entender por qué Patchstack recomienda revisar quién tiene rol Contributor o superior, incluso en sitios donde ese rol parece «de bajo riesgo» porque no tiene permisos de publicación directa.

El resto de los fixes incluye un bug que permitía a visitantes sin autenticar descubrir changesets del Customizer todavía no publicados con una solicitud de vista previa sin ID de changeset (ahora requiere el permiso customize), y un problema donde roles con el permiso moderate_comments podían leer, editar o borrar notas de posts sin tener permiso de edición sobre ese post, algo que solo importa si un rol personalizado, un plugin o un tipo de post separa esos permisos de forma distinta a la configuración estándar. La release también actualiza los certificados raíz empaquetados tras la revocación de eMudhra.

La rama 7.2, con lanzamiento planeado para el 8 de diciembre de 2026, ya incluye estas correcciones desde su Beta 3.

Checklist operativo si administrás uno o varios sitios

Primero lo obvio, sin saltearlo: actualizá a 7.1.4 o al backport de tu rama y confirmá que el proceso terminó, no que quedó «en progreso» colgado en algún lugar. Con eso resuelto, el resto de la lista cambia según el tamaño de tu operación.

Si administrás un solo sitio:

• Agregá una regla de denegación a nivel de servidor (nginx o Apache) para wp-content/upgrade/. Entre actualizaciones esa carpeta solo tiene un index.php, así que la regla no rompe nada y conviene dejarla permanente.
• Revisá los logs web contra el timestamp de tu última actualización, buscando pedidos a setup-config.php bajo wp-content/upgrade/.
• Corré wp core verify-checksums para confirmar que no hay archivos modificados respecto del paquete oficial.
• Revisá quién tiene rol Contributor o superior, aunque te parezca una lista corta y conocida.

Si administrás una agencia o varios sitios: lo anterior, pero automatizado. Un recorrido simple con WP-CLI por cada ruta de instalación te dice de entrada cuáles quedaron atrás sin que tengas que entrar sitio por sitio al panel. Priorizá los que manejan pagos o datos de usuarios, no los que tienen más tráfico: el riesgo de este bug no depende de la audiencia, depende de si la ventana de actualización queda expuesta.

Un matiz que vale repetir porque cambia la estrategia de defensa: un firewall de aplicación en forma de plugin PHP no cubre este ataque específico. La copia que WordPress extrae en staging arranca con sus propios archivos empaquetados, sin la carpeta mu-plugins del sitio en vivo, así que ningún código de firewall del sitio real se carga para esa solicitud. Si tu estrategia de seguridad depende solo de un plugin tipo Wordfence o Sucuri a nivel de aplicación, esta falla puntual se les escapa por diseño, no por un bug del plugin; la regla tiene que vivir un escalón más abajo, en el servidor. Complementamos este enfoque de capas en activar 2FA como defensa adicional y en tener backups resistentes antes de que haga falta restaurar uno.

Si encontrás archivos sueltos en wp-content/upgrade/, un wp-config.php que no reconocés o cuentas de administrador que tu equipo no creó, el protocolo es el de siempre sin saltarse pasos: sitio offline, restauración desde un backup previo al primer cambio sospechoso, reinstalación del core desde un paquete limpio y rotación de contraseñas, salts y credenciales de base de datos.

Qué está confirmado y qué no

Confirmado: CISA incluyó CVE-2026-119977 en su catálogo KEV el 3 de noviembre de 2026, con explotación activa y clasificada como no automatizable pero de impacto técnico total. También está confirmado que WordPress 7.1.4 corrige 22 vulnerabilidades en 17 advisories, que la mayoría de ellas requiere como mínimo un rol Contributor, y que la rama 7.2 ya incorpora estos fixes desde su Beta 3.

No confirmado en las fuentes disponibles: la cantidad exacta de sitios efectivamente comprometidos por el RCE, un exploit de prueba de concepto publicado y validado públicamente, si hubo campañas de ransomware asociadas, y qué porcentaje del ecosistema WordPress seguía sin parchear al 6 de noviembre de 2026. Tampoco hay, en lo que revisamos, casos documentados de explotación real de los bugs de Interactivity API fuera del ejemplo hipotético que planteamos arriba para ilustrar el riesgo.

Errores comunes al responder a esta vulnerabilidad

• Pensar que la fecha límite de CISA no aplica porque no sos una agencia federal. Legalmente no te obliga, pero la lógica de priorización por riesgo real sirve igual para cualquier sitio expuesto.
• Tratar los 22 fixes como «ya los cubrí al actualizar». Actualizar corrige el código; no corrige una lista de roles Contributor mal auditada desde antes.
• Confiar en un firewall de aplicación como único escudo contra el RCE. Un plugin de seguridad en PHP no carga durante la solicitud que explota esta falla puntual.
• Asumir que toda versión menor a 7.1.4 sigue vulnerable igual. Hay backports a varias ramas anteriores; conviene chequear la rama real antes de entrar en pánico.
• Borrar archivos sospechosos antes de preservar evidencia. Si hay indicios de intrusión, el primer paso es guardar logs, no limpiar todo de entrada.

Preguntas Frecuentes

¿Qué cambia que CVE-2026-119977 esté en el catálogo KEV de CISA?

Que CISA confirmó explotación activa, no solo riesgo teórico, y fijó un plazo de remediación obligatorio para agencias federales de EE.UU. Para el resto, sirve como señal de que la urgencia es real y no una recomendación genérica de «mantené todo actualizado».

¿Por qué importa el rol Contributor si mi preocupación es el RCE?

Porque la mayoría de las vulnerabilidades que corrige 7.1.4 requieren, como mínimo, una cuenta con ese rol. Si tu sitio permite que usuarios externos tengan ese nivel de acceso —colaboradores, autores invitados, reseñas de usuarios— conviene auditar esa lista aunque el RCE ya esté parcheado.

¿Un firewall de aplicación me protege de esta falla?

No contra el RCE específico. La copia temporal que WordPress crea en staging arranca sin la carpeta mu-plugins del sitio en vivo, así que ningún plugin de seguridad en PHP se carga para esa solicitud. La defensa tiene que vivir en nginx, Apache o lo que corresponda delante del PHP.

¿Dónde encuentro el detalle completo del CVE y de la telemetría de ataques?

En nuestras dos notas anteriores: el análisis técnico del CVE-2026-119977 y el desglose de los números de Wordfence y GBHackers. Esta nota se enfoca en lo que esas dos no cubrían: el listado KEV y las otras 21 correcciones.

Conclusión

El RCE de CVE-2026-119977 ya tiene su cobertura técnica y su cobertura de números de explotación en otras dos notas de este sitio. Lo que faltaba era conectar dos puntos: qué implica de verdad una fecha límite de CISA para quien no es agencia federal, y por qué el resto de los 22 fixes de WordPress 7.1.4 —casi todos atados a un rol Contributor— merece la misma atención que el bug que salió en los titulares.

Si ya actualizaste a 7.1.4, el checklist que sigue tiene sentido: confirmá la versión real de cada instalación, sumá la regla de denegación a nivel de servidor, y de paso revisá quién tiene rol Contributor o superior en cada sitio que administrás. Ese último punto es el que más fácil se posterga, y es justamente donde viven la mayoría de los problemas que corrigió esta versión.

Fuentes

• Hatamoto – Análisis técnico de CVE-2026-119977 y la respuesta de WordPress 7.1.4
• CISA – Catálogo de Vulnerabilidades Explotadas Conocidas (KEV)
• NVD – Ficha oficial de CVE-2026-119977
• SOC Prime – Telemetría y detección de CVE-2026-119977
• GBHackers – Reporte de intentos de explotación bloqueados