Saltar al contenido

LG y Asus convierten tu sala en un puesto de escucha: un televisor que espía y un router que abre la puerta

Publicado el en Artículos
Fotografía de producto del router Wi-Fi 6 ASUS RT-AX86U Pro.
Imagen: ASUS, asus.com

Vítor Jaime de Oliveira · VitorProDev · Caracas

Alguien se conecta al wifi de invitados de una cafetería, o enchufa un cable en una toma de red olvidada de la pared, y treinta segundos después tiene acceso persistente a toda la red: el router, el NAS sin contraseña, y hasta el televisor de la sala, al que puede convertir en un micrófono encendido. No es ciencia ficción: es el escenario que demostró el canal Gamers Nexus junto al investigador de seguridad conocido como Mr. Bruh, encadenando una vulnerabilidad nueva en routers Asus con fallas ya conocidas en televisores LG. Aquí hay dos responsables, y el más grave es LG: no solo porque su televisor se puede tomar por completo y usar como micrófono, sino porque, incluso sin que nadie lo hackee, ese televisor ya está diseñado para vigilar lo que ves y revender esos datos. Asus pone la puerta de entrada; LG pone el aparato que escucha.

El dato que duele: se estima que la falla del router afecta a unos 35 millones de equipos Asus, prácticamente todo lo que la marca ha vendido con Wi-Fi 6 o superior desde 2018. Y el eslabón del televisor apunta a un parque de 216 millones de televisores LG en el mundo. Pero aquí va la tesis incómoda, y la marco desde ya como mi opinión: entre LG y Asus están convirtiendo los hogares en centros de espionaje financiados por el mejor postor. Un parche tardío o parcial es, en la práctica, un parche que no existe para la mayoría, porque casi nadie actualiza estos equipos a mano; y la responsabilidad de cerrar ese hueco no es del usuario, es del fabricante. Son cifras grandes, así que vale la pena separar con cuidado lo verificado, lo estimado y lo que es opinión. Vamos por partes.

El video, y qué pasa en el minuto 9:51

Toda esta investigación está documentada en el video de Gamers Nexus. Lo embebo aquí porque vale la pena verlo completo:

Si tienes poco tiempo, salta directo al minuto 9:51. Ahí arranca la demostración en vivo: uno de los presentadores ejecuta el exploit contra el router usando un script de prueba de concepto de Mr. Bruh. El script hace dos cosas. Primero se identifica ante el router con un device_id en blanco, lo que provoca un cortocircuito en el código de autenticación y hace que el router entregue un token de administrador que no debería entregar. Segundo, usa ese token para insertar la clave pública SSH del atacante en la configuración del router. A partir de ahí, el atacante es un usuario SSH autorizado: entra sin usuario ni contraseña, y tiene control total del equipo.

Ese minuto resume el corazón del problema: la puerta se abre sin credenciales legítimas, y el router pasa a ser un punto de presencia permanente dentro de la red.

Qué es exactamente la falla del router Asus

La parte técnica tiene dos piezas que se combinan. Conviene entenderlas por separado porque la defensa depende de ello.

Pieza 1: inyección de comandos vía el servidor NTP. Mr. Bruh buscó en el firmware las llamadas a doSystem, un envoltorio que Asus usa para ejecutar comandos de Linux. Encontró 109 usos y, revisando solo 7, dio con un manejador vulnerable: el que actualiza el servidor NTP del router. Ese código toma los primeros 32 caracteres del valor ntp_server0 guardado en NVRAM y se los pasa a nslookup sin sanitizar. Usando un metacarácter como ; se puede escapar del comando previsto y ejecutar un segundo comando propio. El ejemplo que publica el investigador es ;telnetd -l/bin/sh -p9999;, que cabe en 26 de los 31 caracteres utilizables y abre una shell por telnet. El problema es que ese endpoint exige un token de administrador. Y ahí entra la segunda pieza.

Pieza 2: el bypass de autenticación. Para refrescar el token, la app móvil de Asus cifra la hora actual y la MAC del router con un secreto compartido, y envía ese paquete junto a un device_id. El router inicializa el secreto como una cadena vacía; si encuentra el device_id en NVRAM, lo reemplaza por el secreto real. El fallo: no sale temprano si el device_id no existe. Entonces un atacante puede cifrar la hora y la MAC del router (ambos datos fáciles de obtener) usando una clave en blanco, enviar un device_id inválido, y el router descifra el paquete con la clave vacía, lo valida y entrega un token de administrador.

Con ese token, la cadena completa es: forjar el token → habilitar SSH → añadir la clave pública del atacante → entrar por SSH → shell con control total. Hay una variante más ruidosa vía NTP, pero la del SSH es la más fiable según el propio investigador.

Un matiz importante que juega a tu favor: el bypass NO funciona si nunca emparejaste el router con la app móvil de Asus. Si un device_id jamás se registró, la lista está vacía y el exploit falla con un error 400. En palabras del investigador, quien evitó usar la app puede sentirse tranquilo. El problema es que la app registra más de 5 millones de descargas solo en Android.

[FUENTE PENDIENTE]: el detalle de que el aislamiento de la red de invitados solo cubre IPv4 y podría sortearse por IPv6 proviene del relato del investigador y no lo pude confirmar con una fuente primaria independiente.

El salto al televisor LG: encadenamiento de exploits

Una vez dentro de la red, el router es un trampolín. El atacante ve el mapa de clientes, las MAC, las contraseñas del wifi en texto plano y la IP de cada dispositivo, incluido el televisor. Desde ahí, estando en la misma LAN y conociendo la IP del televisor, se encadena con una cadena de fallas de webOS documentada de forma independiente por SSD Secure Disclosure.

Televisor LG 32LQ636BPSA con webOS, fotografía de producto.
Imagen: LG, lg.com
Diagrama del salto: un router, la red local y un televisor, en ese orden.
Diagrama: VitorProDev

Esa cadena del televisor tiene tres pasos verificados en el aviso de SSD:

  1. Replay del manifiesto firmado de sync-demo. La app com.webos.app.sync-demo trae un manifiesto firmado con un certificado de prueba que el firmware todavía confía. Al reproducirlo, el televisor salta el PIN de emparejamiento y entrega una client-key privilegiada, porque el manifiesto incluye el permiso STB_INTERNAL_CONNECTION.
  2. SSRF vía cmp-client. La app cmp-client acepta un interactiveUrl sin validar esquema ni host, y navega a contenido del atacante. Esa página mantiene acceso a PalmServiceBridge, la interfaz interna hacia los servicios del sistema.
  3. Inyección de comandos en pmlogd. El servicio de logging construye comandos de shell con el campo targetDir sin sanitizar. Como PmLogDaemon corre como root, el comando inyectado se ejecuta como root.

El resultado práctico: acceso root al televisor sin PIN ni interacción del usuario, solo estando en la red. Con eso se puede grabar del micrófono integrado y enviar el audio a un servidor del atacante, e incluso mostrar un falso mensaje de «actualización en progreso» para que nadie desenchufe el aparato mientras graba.

Los datos: verificado vs. pendiente

Aquí separo lo que pude confirmar con fuentes primarias de lo que es estimación o quedó sin confirmar.

Dato Estado Fuente
~35 millones de routers Asus afectados Estimación (del investigador, calculada con ayuda de IA) mrbruh.com/asusrouter
Afecta a modelos Wi-Fi 6 y posteriores, de 2018 en adelante Estimación (búsqueda binaria sobre versiones de firmware) mrbruh.com/asusrouter
Inyección de comandos vía ntp_server0 + doSystem/nslookup Verificado (descripción técnica del investigador) mrbruh.com/asusrouter
Bypass de autenticación por secreto en blanco con device_id inválido Verificado (descripción técnica del investigador) mrbruh.com/asusrouter
El bypass no funciona si nunca se emparejó la app móvil Verificado (prueba del investigador) mrbruh.com/asusrouter
Cronología: reporte 27/06/2026; ack 01/07/2026; beta 19/08/2026; fin de los 90 días 26/09/2026 Verificado (cronología del investigador, formato DD/MM/YYYY) mrbruh.com/asusrouter
Fecha estimada por Asus para el firmware corregido: 15/11/2026 (aún futura al cierre de este artículo) Verificado como estimación del fabricante, no como hecho consumado mrbruh.com/asusrouter
Asus pidió extensión de 30 días; estimó parches entre fin de octubre y mediados de noviembre de 2026 Verificado (cita textual del correo de Asus) mrbruh.com/asusrouter
App móvil de Asus con +5 millones de descargas en Android Verificado (dato de la Play Store citado por el investigador) mrbruh.com/asusrouter
CVE-2026-75753: Falta de autenticación en routers Asus Verificado (existe el registro) GitHub Advisory · NVD
CVE-2026-75753 corresponde EXACTAMENTE a esta cadena RCE [FUENTE PENDIENTE] N/D
Versión de firmware corregida concreta por modelo [FUENTE PENDIENTE] N/D
216 millones de televisores LG en el mundo Verificado (cifra de LG Ad Solutions, reportada por prensa) Cybernews
Cadena webOS: replay de manifiesto + SSRF cmp-client + inyección pmlogd = root Verificado SSD Secure Disclosure
Cadena webOS probada en LG 32LQ636BPSA y 27TQ600SW, webOS 7.5.7-25, firmware 04.54.40 Verificado SSD Secure Disclosure
LG publicó corrección (5 fallas de alta severidad, en septiembre de 2026) Verificado Cybernews · boletín LG
Cuántos modelos LG están afectados en total [FUENTE PENDIENTE] N/D
CVE asignados a la cadena de webOS [FUENTE PENDIENTE] (al cierre no había identificadores publicados) The Hacker News
CVE-2026-75753 en el catálogo KEV de CISA Verificado que NO está (al 21/10/2026) CISA KEV
Explotación activa en la naturaleza [FUENTE PENDIENTE] (no hay reportes confirmados) N/D

Una nota de rigor sobre las CVE: en el KEV de CISA, al 21 de octubre de 2026, las entradas de Asus que aparecen son CVE-2021-32030, CVE-2023-39780 y CVE-2018-14839, ninguna de ellas es esta falla nueva. La única CVE reciente que encontré ligada a routers Asus con fecha de estos días es CVE-2026-75753, pero su descripción pública («falta de autenticación que permite a un usuario cercano obtener información de identificación y pasar a un modo específico») no coincide palabra por palabra con la cadena RCE completa que describe Mr. Bruh, así que no afirmo que sean la misma. Lo dejo marcado como [FUENTE PENDIENTE].

El veredicto: dos fabricantes, una misma lógica

Ilustración de Halloween: un router y un televisor genéricos, encadenados, comparecen ante un juez en un tribunal infernal.
Ilustración generada con IA para VitorProDev

Lo que sigue es, en gran parte, opinión del autor, y lo señalo con claridad; los hechos que la sostienen van con su fuente. Mi tesis: entre LG y Asus están convirtiendo los hogares en centros de espionaje financiados por el mejor postor. El reparto de culpa no es parejo. El peso cae más sobre LG, y aquí explico por qué.

El caso contra LG (lo más grave)

El problema de LG tiene dos capas, y ambas están documentadas.

La primera es la falla de seguridad. La firma SSD Secure Disclosure publicó una cadena de exploits en webOS (replay de un manifiesto firmado de sync-demo, un SSRF en cmp-client vía PalmServiceBridge y una inyección de comandos en pmlogd) que da acceso root al televisor sin PIN ni interacción del usuario, solo estando en la misma red. Con ese acceso se puede grabar del micrófono integrado y enviar el audio a un servidor del atacante (SSD Secure Disclosure). Es decir: el televisor se puede usar como micrófono. Eso es un hecho verificado, no una hipótesis.

La segunda capa es la que, en mi opinión, pesa más, porque no depende de ningún atacante: el propio modelo de negocio del televisor. LG reconoce en su política de privacidad que usa Automatic Content Recognition (ACR), la función comercial llamada Live Plus, para identificar el contenido que ves, y que esa información de visionado puede compartirse con LG Ad Solutions, su afiliada publicitaria, para segmentación de audiencias y, con consentimientos adicionales, publicidad basada en intereses y entre dispositivos (Understanding Privacy on LG Smart TVs). La propia LG admite que, en ciertos mercados, esa información de visionado puede compartirse de formas que la ley considera «venta» o «sharing» de datos personales, y que puede transferirse a otros países, incluida Corea (política de LG; Viewing Information Agreement de LG, que nombra a su socio Alphonso).

Que esto no es un tecnicismo lo confirma la vía judicial. En diciembre de 2025, una demanda de la Fiscalía de Texas acusó a cinco fabricantes de televisores (entre ellos LG) de usar ACR para registrar lo que ven los usuarios y vender esos datos sin su consentimiento informado (demanda de la Fiscalía de Texas, 17/12/2025). En mayo de 2026, LG cerró un acuerdo en ese caso y se comprometió a no usar ACR para recopilar datos de visionado sin consentimiento informado, a mostrar un aviso emergente que explique cómo se recopilan y usan esos datos, y a ofrecer una forma clara y sencilla de exclusión (acuerdo de la Fiscalía de Texas con LG, 11/05/2026). Un acuerdo no es una condena, y en honor a la verdad LG sostiene que ACR está desactivado por defecto y requiere aceptar su acuerdo de visionado (política de LG). Pero que haya hecho falta una demanda para forzar avisos claros y una exclusión sencilla dice bastante sobre las prioridades de partida.

Lo de «financiados por el mejor postor» es mi lectura del modelo, no una acusación de hecho: se apoya en que LG opera una división publicitaria (LG Ad Solutions) cuyo negocio es justamente monetizar datos de audiencia, y en que la propia LG reconoce compartir información de visionado con ella y, en algunos mercados, «venderla» o «compartirla» en el sentido legal (política de LG). Si esa compartición alcanza a terceros más allá de la cadena LG-Alphonso, y en qué términos económicos, queda como [FUENTE PENDIENTE].

El caso contra Asus (grave, pero menor)

Asus hizo lo que mejor se le da cuando hay una falla: ir lento. El estándar de la industria son 90 días (el modelo de divulgación coordinada que siguen equipos como Project Zero), y Asus no lo cumplió. Según la cronología del investigador, tuvo firmware beta funcional dos meses después del reporte (19/08/2026), pero dejó vencer el plazo el 26/09/2026 sin despliegue completo y pidió 30 días más, hasta el 15/11/2026. Y lo más difícil de defender: poco después de que se rechazara la extensión, empezó a publicar un parche no-beta para algunos modelos. Si el arreglo ya estaba listo, ¿para qué pedir más tiempo? (mrbruh.com/asusrouter).

Lo que convierte ese retraso en un problema real, y no en un trámite, es que la mayoría de los usuarios nunca actualiza su router ni sus equipos conectados a mano. 1 Sobre ese mundo aterriza un parche: si el usuario tiene que ir a buscarlo, no va a ir. Por eso un parche tardío o parcial deja a millones de equipos expuestos de forma indefinida.

El criterio común

De ambos casos sale, en mi opinión, un único criterio para cualquier aparato conectado de este tipo: o las actualizaciones de seguridad vienen activadas por defecto y se instalan solas (y la recopilación de datos viene desactivada por defecto y es fácil de rechazar), o el equipo no es seguro. No hay término medio. Un televisor que vigila salvo que el dueño sepa entrar a desactivar Live Plus, y un router que solo se parchea si su dueño va a buscar el firmware, están diseñados para dejar al usuario desprotegido. La carga no puede recaer en quien compra; recae en quien fabrica y vende.

Siendo justos con los tiempos de reacción: LG publicó la corrección de las fallas de webOS en septiembre de 2026 (Cybernews; boletín de LG), una ventana razonable; Asus, para la misma clase de riesgo, sigue estimando noviembre. En velocidad de parcheo, LG quedó por delante. Pero el reproche de fondo a LG no es la velocidad del parche de seguridad, sino que su televisor espíe por diseño aunque nadie lo ataque. Por eso el enojo pesa más sobre LG.

Cronología de la divulgación (fuente: mrbruh.com/asusrouter, formato DD/MM/YYYY)

Las fechas provienen de la cronología que publica el propio investigador. Todas corresponden al año 2026. La última es una estimación del fabricante, aún futura al momento de escribir este artículo (22 de octubre de 2026).

Fecha Hito
27/06/2026 Reporte enviado a Asus
01/07/2026 Asus acusa recibo del reporte
03/08/2026 El investigador pide una actualización de estado
07/08/2026 Asus acepta 3 de 4 fallas (una era duplicada)
19/08/2026 Asus entrega firmware beta
04/09/2026 El investigador pide otra actualización de estado
26/09/2026 Termina el plazo de divulgación de 90 días
15/11/2026 Fecha estimada por Asus para el firmware corregido (estimación, aún futura)

Fuente de todas las fechas: mrbruh.com/asusrouter. La corrección de LG a sus televisores se publicó en septiembre de 2026, según Cybernews y el boletín de LG.

Qué hacer hoy

No esperes al parche oficial para blindarte. Estas medidas aplican tanto si tienes un router Asus como cualquier otro, y valen incluso cuando aún no hay firmware corregido disponible.

1. Actualiza el firmware.

  • Entra al panel del router por el navegador en la IP local (normalmente 192.168.50.1 en Asus) y busca la sección de actualización de firmware. Aplica la última versión disponible.
  • Versiones corregidas concretas por modelo: [FUENTE PENDIENTE]. Asus estimó el despliegue completo entre fin de octubre y mediados de noviembre de 2026, así que revisa de nuevo en los próximos días.
  • Para el televisor LG, revisa el boletín de LG (lgsecurity.lge.com/bulletins/tv) y actualiza desde Configuración → Soporte → Actualización de software.
  • Cómo comprobarlo: anota la versión instalada antes y después; en Asus la ves en la pantalla de administración; en LG, en Configuración → Soporte → Información del TV.

2. Desactiva el acceso remoto, la WAN de administración y AiCloud.

  • En el router, desactiva la administración remota desde la WAN, el acceso DDNS innecesario y AiCloud/AiDisk si no los usas. La administración debe ser solo local.
  • Desactiva SSH y telnet salvo que los necesites; si los usas, restríngelos a la LAN.
  • Cómo comprobarlo: desde fuera de tu red (por ejemplo, con los datos del móvil), intenta abrir el panel del router por su IP pública. No debería responder. Comprueba que el puerto de administración remota esté cerrado.

3. No emparejes la app móvil ni vincules cuentas.

  • Configura el router solo por el navegador, en local. Según el propio investigador, no haber emparejado la app móvil es justo lo que rompe el bypass de autenticación.
  • Si ya la emparejaste, desvincula el dispositivo y considera restaurar de fábrica tras actualizar.

4. Segmenta la red y mete los IoT en su propia VLAN o red de invitados.

  • Pon televisores, cámaras, NAS y cacharros IoT en una VLAN separada o en una red de invitados con aislamiento de clientes activado, para que un equipo comprometido no pueda saltar al resto.
  • Activa el aislamiento de clientes (AP/client isolation) en la red de invitados.
  • Cómo comprobarlo: desde un dispositivo en la red de invitados, intenta hacer ping o abrir el panel del router en la IP de administración. Si está bien segmentado, no deberías alcanzarlo. Escanea con una herramienta de red para confirmar que no ves los equipos de la red principal.

5. Cambia usuarios y contraseñas por defecto, en todo.

  • Trata el nombre de usuario como una segunda contraseña: evita admin o root. Pon credenciales fuertes también en el NAS y en cualquier dispositivo que creas «solo local», porque el encadenamiento de exploits convierte lo local en alcanzable.
  • Cómo comprobarlo: revisa que ningún equipo de la red siga con credenciales de fábrica; en el NAS, verifica que exija usuario y contraseña robustos.

6. En el televisor LG, desactiva el ACR (Live Plus) y la publicidad basada en datos.

  • Desactiva Live Plus, la función que aplica ACR: Configuración → General → Sistema → Configuración adicional → Live Plus → Desactivado (Viewing Information Agreement de LG; guía de pasos).
  • Retira el consentimiento de los acuerdos: Configuración → Soporte → Privacidad y términos → Acuerdos de usuario, y desmarca el Acuerdo de Información de Visionado, el de Voz y el de Publicidad.
  • Activa «Limitar seguimiento de anuncios» (Limit Ad Tracking) y, donde aplique, envía la solicitud «Do Not Sell My Personal Information».
  • Nota: según el propio acuerdo de LG, desactivar «Do Not Sell» no detiene el ACR; para pararlo hay que apagar también el toggle de Live Plus (acuerdo de LG).
  • Cómo comprobarlo: vuelve a Configuración adicional y confirma que Live Plus sigue en «Desactivado», y revisa en Acuerdos de usuario que las casillas quedaron sin marcar.

En resumen

Lo verificado: existe una cadena real que convierte un router Asus sin parchear en un trampolín hacia otros equipos de la red, y una cadena de webOS que da root en ciertos televisores LG y permite usarlos como micrófono. Además, por diseño, los televisores LG usan ACR (Live Plus) para identificar lo que ves y compartir esos datos con su afiliada publicitaria, algo que llevó a una demanda y a un acuerdo en Texas. Ambos fabricantes ya tienen correcciones de seguridad, parcial en el caso de Asus. Lo estimado: las cifras de 35 millones de routers y 216 millones de televisores son magnitudes del universo potencial, no de equipos comprometidos. Lo que es opinión del autor: que entre ambos convierten los hogares en centros de espionaje financiados por el mejor postor. Lo pendiente: la coincidencia exacta de CVE, las versiones corregidas por modelo, el alcance económico de la reventa de datos y si hay explotación activa. Mientras tanto, actualizar, segmentar, no vincular la app móvil del router y desactivar Live Plus en el televisor te quita de encima casi todo el riesgo hoy mismo.


  1. Como referencia del comportamiento de los usuarios, una encuesta de Broadband Genie a 3.045 personas en el Reino Unido (2024) halló que el 89 % nunca había actualizado el firmware de su router. El dato es solo de routers y solo del Reino Unido, así que lo dejo como respaldo y no como cifra global: ISPreview, citando a Broadband Genie. ↩

End of article