La prueba convierte un mensaje en una cadena de tres fallos
Una investigación de Orange Cyberdefense Switzerland publicada el 22 de septiembre de 2026 ha demostrado que un mensaje enviado al chat de Twitch puede terminar ejecutando código nativo en el ordenador de una persona que retransmite con OBS Studio 32.2.2 sobre Windows 11. El resultado es serio, pero depende de una combinación concreta y no de un fallo aislado de Twitch ni de una instalación limpia de OBS.
El primer eslabón es un overlay de chat creado de forma insegura: en lugar de mostrar el mensaje del espectador como texto, lo inserta como HTML sin sanear. Eso permite ejecutar JavaScript dentro de una Browser Source. A partir de ahí, la prueba aprovecha un Chromium integrado antiguo y una vulnerabilidad de V8 para pasar del contenido web al código nativo. La tercera condición es que ese navegador embebido funciona sin la sandbox habitual que separa una página del sistema operativo.
No cualquier usuario de OBS queda expuesto por abrir Twitch
La divulgación no sostiene que cualquier persona con OBS pueda ser atacada desde un chat. Para repetir la entrada remota y sin clics de la demostración, el streamer debe haber añadido una fuente o widget que trate contenido controlado por espectadores como HTML. El servidor WebSocket de OBS no interviene en la cadena: está desactivado por defecto y, cuando se habilita, genera una contraseña.
La distinción importa porque evita confundir tres superficies distintas. Twitch transporta el mensaje; el overlay decide cómo lo representa; y OBS ejecuta esa página dentro de su navegador integrado. La vulnerabilidad aparece cuando fallan las tres barreras. Un chat que renderiza los mensajes como texto no ofrece la misma entrada, y una instalación que no carga contenido web de procedencia dudosa tampoco reproduce por sí sola el escenario investigado.
La pieza conocida es una vulnerabilidad de V8 ya explotada
La prueba utiliza CVE-2024-7971, un error de confusión de tipos en el motor V8 de Chromium. NIST sitúa el corte de la corrección en Chromium 128.0.6613.84. Microsoft documentó en 2024 que un grupo norcoreano había usado el fallo para lograr ejecución remota dentro del proceso de renderizado de Chrome, y CISA lo incorporó a su catálogo de vulnerabilidades explotadas.
Eso no demuestra que la nueva cadena contra OBS se esté usando en ataques reales. Lo confirmado es que la vulnerabilidad de navegador tuvo explotación previa y que el investigador consiguió adaptarla al Chromium 127 incluido en OBS 32.2.2. No se han publicado víctimas de esta prueba, campañas activas contra streamers ni casos en España. La ausencia de esos datos no elimina el riesgo técnico, pero limita lo que puede afirmarse sobre su alcance.
OBS 33 cambia el navegador, aunque todavía es una versión de prueba
El proyecto OBS ya había trabajado durante meses en sustituir su navegador integrado. El repositorio oficial muestra que la actualización compatible con CEF y Chrome Runtime se fusionó el 10 de septiembre, y las notas de OBS Studio 33.0 beta elevan CEF desde Chromium 127 hasta Chromium 150. Ese salto corrige la vulnerabilidad de V8 empleada en la demostración y moderniza las Browser Sources y los docks.
La versión estable más reciente continúa siendo OBS Studio 32.2.2, publicada el 14 de agosto. OBS 33.0.0-beta4 es una prepublicación: el propio proyecto recomienda hacer copia de las colecciones de escenas y perfiles, avisa de que puede contener fallos y mantiene la versión estable como opción para producción. La beta reduce el problema concreto del navegador antiguo, pero probarla no equivale a una recomendación universal para canales que no pueden asumir interrupciones.
Qué cambia para creadores y equipos de streaming en España
OBS distribuye las mismas versiones a usuarios de España y no ha anunciado una variante geográfica del problema. La comprobación relevante no es el país, sino la versión instalada y la procedencia de cada Browser Source, dock o widget que procesa datos de terceros. Los overlays personalizados, los generados rápidamente y los que ya no reciben mantenimiento merecen más atención que un chat abierto en la web de Twitch.
Mientras la actualización del navegador llega a una versión estable, la mitigación más directa está en la capa que inició la prueba: no cargar overlays desconocidos y evitar cualquier widget que inserte mensajes, nombres o alertas como HTML sin saneamiento. Para quien desarrolla esos componentes, el contenido de los espectadores debe representarse como texto salvo que exista una necesidad real de HTML y un saneamiento correcto. Actualizar Windows o el navegador habitual no sustituye la actualización del Chromium que OBS empaqueta dentro de la aplicación.
La próxima señal será la versión estable y el regreso de la sandbox
La actualización a Chromium 150 resuelve el fallo de V8 concreto que hizo posible esta demostración, pero la arquitectura sigue teniendo otra pregunta abierta: cuándo podrá activarse de nuevo la sandbox del navegador sin romper integraciones y autenticaciones. El equipo de OBS estaba probando ese cambio cuando se coordinó la divulgación. Recuperar esa separación obligaría a un atacante a superar una barrera adicional incluso si apareciera otra vulnerabilidad del motor web.
Hasta que OBS 33 salga de beta, el estado correcto es menos rotundo que «parchado» o «sin parche». El código actualizado ya existe y puede probarse; la versión estable todavía incorpora el motor antiguo; y el proyecto no ha publicado una corrección separada para 32.2.2. La fecha de la versión estable, el resultado de las pruebas de compatibilidad y la decisión final sobre la sandbox son los tres datos que determinarán cuándo se cierra por completo esta ventana de riesgo.
