Zoomsday tomaba una reunión entera: actualizar Zoom corta el ataque
El 13 de agosto de 2026 se difundió Zoomsday, una cadena de vulnerabilidades ya corregida que permitía a un participante ejecutar código en los clientes de otros asistentes mediante una anotación manipulada. La cobertura técnica de Tom’s Hardware confirmó que el ataque no exigía usar activamente la pizarra y que las correcciones ya estaban disponibles.
La acción que corta la cadena documentada es actualizar Zoom Workplace: la rama 7.0 debe alcanzar al menos la versión 7.0.6 y la rama 7.1, la 7.1.5. El atacante tenía que participar en la reunión, pero la víctima no necesitaba abrir un archivo, aceptar una descarga ni hacer clic.
Cómo una anotación alcanzaba a los demás clientes
Las anotaciones de Zoom no circulan como imágenes terminadas. Trazos, textos y formas se convierten en objetos estructurados, atraviesan la infraestructura de la reunión y se reconstruyen en el cliente receptor. El fallo aparecía porque el código nativo confiaba en cantidades y longitudes declaradas por el remitente al reservar o copiar memoria.
El informe técnico de A Security documenta que una anotación de texto podía desbordar búferes fijos y que otra lectura fuera de límites podía revelar datos útiles para sortear ASLR; también sitúa el hallazgo el 8 de junio, el aviso a Zoom el 10 de junio, la primera corrección del cliente el 22 de junio, la mitigación del servidor el 15 de julio, el cierre adicional en la versión 7.1.5 el 20 de julio y la divulgación pública el 11 de agosto. El equipo afirma que pasó del hallazgo a un exploit funcional en menos de 24 horas y con menos de 20 instrucciones a un agente de IA.
La función de anotación seguía procesando mensajes aunque los asistentes no estuvieran dibujando ni escribiendo sobre una pantalla compartida. Desde la posición de quien compartía, el canal permitía dirigirse por separado a los participantes; desde el puesto de un asistente, el mismo recorrido podía alcanzar al presentador. Esa asimetría explica el gancho del nombre: una anotación enviada desde la posición adecuada podía comprometer a todos los demás clientes de la reunión.
El resultado era ejecución de código con los permisos del proceso de Zoom y de la cuenta activa. Eso no equivale automáticamente a privilegios de administrador ni a control del núcleo del sistema, pero sí podía exponer archivos y credenciales accesibles, aprovechar permisos ya concedidos a cámara o micrófono y lanzar una segunda etapa dentro de esos límites.
Qué versiones cierran la cadena conocida
El boletín ZSB-26015 de Zoom clasifica CVE-2026-53413 como una vulnerabilidad de severidad alta, confirma que un participante podía lograr ejecución remota contra otro y fija estos umbrales:
- Zoom Workplace, rama 7.1: están afectadas las versiones anteriores a 7.1.5.
- Zoom Workplace, rama 7.0: están afectadas las versiones anteriores a 7.0.6.
- Zoom Workplace VDI Client para Windows: están afectadas las versiones anteriores a 7.0.11 y 6.6.16 en sus ramas respectivas.
- Zoom Rooms: están afectadas las versiones anteriores a 7.1.0.
- Zoom Meeting SDK: están afectadas las versiones anteriores a 7.1.0.
Los números no forman una sola secuencia ascendente. Un cliente administrado en la rama 7.0 puede estar corregido en 7.0.6, mientras uno de la rama 7.1 necesita 7.1.5. En una flota empresarial también hay que separar el cliente Workplace convencional de VDI, Rooms y las aplicaciones que incorporan Meeting SDK.
Por qué el filtro del servidor no bastaba
Zoom desplegó una mitigación capaz de filtrar mensajes de anotación maliciosos antes de que llegaran a clientes antiguos. Esa barrera no cubría las reuniones con cifrado de extremo a extremo: en ese modo, el servidor no podía inspeccionar el contenido para reconocer la estructura manipulada.
El cifrado tampoco neutralizaba por sí mismo al atacante, porque este ya era un participante legítimamente conectado y disponía de las claves necesarias para intercambiar mensajes dentro de la reunión. Por eso la actualización local es la corrección decisiva: evita que el cliente vulnerable reconstruya el objeto de la forma que hacía posible la cadena, sin depender de que el servidor pueda leerlo.
Qué aporta la IA al caso Zoomsday
La IA no descubrió ni explotó el fallo sin trabajo especializado. La investigación incluyó descompilar el cliente Android, clasificar bibliotecas nativas, observar una reunión real, reconstruir un protocolo propietario y validar el control de la ejecución en clientes receptores.
El primer barrido automatizado priorizó miles de funciones, pero colocó la biblioteca de anotaciones lejos de los primeros puestos. El avance llegó al cambiar la pregunta: en vez de buscar únicamente funciones peligrosas, el equipo rastreó qué datos podía controlar realmente otro participante. Ese enfoque condujo al componente expuesto al protocolo de la reunión.
El caso muestra que los agentes pueden abaratar la clasificación de superficies extensas, la generación de hipótesis y la preparación de pruebas, aunque la instrumentación y la validación humana sigan siendo necesarias. Es una dinámica relacionada con otros agentes que buscan fallos: el intervalo entre localizar un defecto complejo y construir una prueba funcional puede reducirse frente a los ciclos tradicionales de actualización.
Qué queda por comprobar en una flota
Instalar el parche no basta si el inventario sigue mostrando clientes antiguos. La comprobación debe hacerse sobre la versión efectiva de cada producto y cada rama: 7.0.6 o 7.1.5 para Zoom Workplace, además de los umbrales propios de VDI, Rooms y Meeting SDK.
Los bloqueos inesperados durante reuniones pueden conservar indicios de intentos fallidos. También merecen revisión los navegadores, intérpretes de comandos o scripts iniciados como procesos secundarios de Zoom, porque la demostración pública produjo precisamente una ejecución local desde el cliente. Ninguna de estas señales prueba por sí sola que hubo explotación; debe correlacionarse con la hora de la reunión, los participantes y la telemetría del dispositivo.
El estado confirmado es que Zoom publicó correcciones para la cadena documentada y que actualizar elimina ese recorrido conocido. La cuestión operativa ya no es si existe un parche, sino cuántos clientes administrados, equipos de invitados e integraciones permanecen por debajo de la versión que corresponde a su rama.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.