Se ha descubierto una vulnerabilidad en TightVNC Viewer que permite a los atacantes ejecutar código en PCs con Windows incluso antes de que aparezca la solicitud de contraseña. La investigación, realizada por SeongJoon Cho de SSD Labs Korea, incluye un código de prueba (PoC) dirigido a la versión 2.8.88 x64, el cual utiliza un servidor VNC malicioso para enviar datos de pantalla que corrompen la memoria del visor.

Una vulnerabilidad en TightVNC Viewer puede permitir que los atacantes ejecuten código en PCs con Windows antes de que aparezca la solicitud de contraseña. La investigación acreditada a SeongJoon Cho de SSD Labs Korea incluye un código de explotación de prueba de concepto (PoC) dirigido a TightVNC 2.8.88 x64. El ataque utiliza un servidor VNC malicioso para enviar datos de pantalla que corrompen la memoria del visor.

El componente afectado es el visor, no cualquier máquina con Windows que ejecute un servidor TightVNC. Los atacantes necesitan acceso a la red de un visor en Modo de Escucha (Listening Mode) o un usuario que conecte el visor a un servidor controlado por el atacante. La divulgación proporcionada no establece una explotación activa.

El fallo comienza cuando el servidor anuncia el tamaño de su pantalla a través del protocolo Remote Framebuffer (RFB). TightVNC calcula la memoria necesaria para albergar esa pantalla, pero convierte el resultado en un entero de 32 bits. Las dimensiones grandes provocan que el valor se desborde (wrap around), dejando una asignación menor de la esperada.

En el ejemplo reportado, un servidor anuncia una pantalla de 32,768 por 32,769 usando 32 bits por píxel. El visor asigna solo 128 KB mientras mantiene dimensiones que representan más de 4 GB de datos de píxeles. Las actualizaciones posteriores de la pantalla escriben fuera de ese pequeño búfer porque el cálculo del puntero carece de una comprobación frente al tamaño asignado.

Vulnerabilidad de RCE Pre-Autenticación de TightVNC

El PoC convierte esta corrupción de memoria en ejecución de código. Primero cambia la longitud de un búfer de salida para filtrar la memoria cercana, revelando las direcciones necesarias para evadir la aleatorización de direcciones (ASLR).

Luego redirecciona una llamada a una función y utiliza la programación orientada a retornos (ROP), que reutiliza código existente, para lanzar un proceso a través de la función CreateProcessW de Windows.

El Modo de Escucha expone el visor en el puerto TCP 5500 y, según la divulgación, acepta conexiones de servidores entrantes sin contraseña ni restricción de IP.

Un atacante que pueda alcanzar ese puerto puede atacar el visor directamente. Una conexión saliente a un servidor de soporte fraudulento crea otra ruta, donde la explotación ocurre antes de la autenticación.

Estas condiciones difieren del secuestro de conexiones VNC que se basa en contraseñas débiles. También difieren de las herramientas de acceso remoto disfrazadas de instaladores, donde los usuarios instalan software legítimo bajo falsos pretextos. Aquí, el ataque se dirige al manejo de la memoria dentro del propio visor.

Los investigadores afirman que el proveedor no respondió y que parcheó el problema el 3 de octubre de 2026. Sin embargo, los avisos de lanzamiento oficiales de TightVNC identifican actualizaciones de seguridad el 2 y el 5 de octubre, por lo que la fecha exacta de la corrección sigue sin estar clara. El proveedor indica que las versiones 2.8.89 y 2.8.90 solucionan los problemas de seguridad del visor y recomienda la 2.8.90 para esa rama.

Debes actualizar los visores afectados, desactivar el Modo de Escucha innecesario, restringir el puerto 5500 a sistemas confiables y evitar servidores VNC no confiables. Las restricciones de red reducen la exposición, pero no sustituyen el parcheo del visor vulnerable.