La vulnerabilidad de ejecución remota de código (RCE) que AMD dijo que no corregirá

• Se descubrió y reportó una vulnerabilidad de ejecución remota de código (RCE) en el software AutoUpdate de AMD, pero AMD decidió no corregirla
• La URL almacenada en el archivo de configuración de actualización está configurada para descargar ejecutables usando el protocolo HTTP, por lo que es vulnerable a MITM (ataque de intermediario)
• El software está diseñado para ejecutar de inmediato los archivos descargados sin realizar verificación de firma
• AMD clasificó este problema como “fuera de alcance (out of scope)” y no lo reconoció como una vulnerabilidad de seguridad
• Aunque existe el riesgo de que un atacante en la red pueda distribuir ejecutables maliciosos, se señala como una preocupación de seguridad el hecho de que no se proporcione un parche

---

Cómo se descubrió la vulnerabilidad RCE de AMD AutoUpdate

• Mientras se rastreaba un problema de una ventana de consola que aparecía periódicamente en una nueva PC gamer, se confirmó que la causa era el ejecutable AMD AutoUpdate
• Durante el proceso de descompilar el programa, se descubrió por casualidad una vulnerabilidad RCE
• La URL de actualización está almacenada en el archivo app.config, y en el entorno de producción también se usa una URL de desarrollo (Development)
• Esa URL usa HTTPS, pero los enlaces reales de descarga de ejecutables están en HTTP

Problemas técnicos de la vulnerabilidad

• Como los ejecutables se descargan por HTTP, un atacante dentro de la red o incluso a nivel de ISP puede manipular la respuesta y reemplazarla por un archivo malicioso
• El programa AutoUpdate no realiza verificación del certificado ni de la firma de los archivos descargados
• Como resultado, existe una estructura en la que un atacante puede distribuir un ejecutable arbitrario y el programa puede ejecutarlo de inmediato

Respuesta de AMD y resultado del reporte

• Tras descubrir la vulnerabilidad, se reportó a AMD, pero el caso fue cerrado al clasificarse como “no se corregirá (won’t fix)” y “fuera de alcance (out of scope)”
• AMD no considera esta vulnerabilidad un problema de seguridad
• El calendario del reporte y la divulgación fue el siguiente
  • 27/01/2026: descubrimiento de la vulnerabilidad
  • 05/02/2026: reporte a AMD
  • 05/02/2026: cierre como “wont fix/out of scope”
  • 06/02/2026: publicación en el blog

Implicaciones de seguridad

• Una estructura de actualización basada en HTTP y la ausencia de verificación de firma pueden exponer los sistemas de los usuarios a ataques de ejecución remota de código
• La decisión de AMD de no corregir este problema implica la posibilidad de controversia dentro de la comunidad de seguridad
• Si existe un atacante en la red, hay riesgo de que se abuse de esto como una vía de distribución de malware

[GN⁺]

Opiniones en Hacker News

• Una buena razón por la que Linux incluye todos los controladores es que así no hace falta instalar software de gestión de controladores de baja calidad o tipo spyware
  Estos programas son difíciles de aislar en sandbox y representan un riesgo de seguridad
  Curiosamente, parece que los mantenedores de distribuciones que trabajan gratis son mucho más competentes en seguridad que los fabricantes de hardware de miles de millones de dólares

  • No es que los fabricantes de hardware sean incapaces en seguridad, sino que sus prioridades son otras
    A los mantenedores de distribuciones les importa la seguridad, pero para los fabricantes es más importante lanzar rápido la siguiente generación de hardware
    Al final, ambos grupos tienen objetivos distintos
  • Creo que esta calidad se mantiene gracias a la organización que creó Linus y a los muchísimos contribuidores que participan en ella
    Hay unas pocas personas influyentes haciendo un buen trabajo en silencio
    Lo tomo como una señal de que la gente que no sale en las noticias es la que de verdad sabe
  • Ryzen Master no es un controlador
    La mayoría de sus funciones no se pueden usar en Linux
  • No está claro si el problema del post original es un tema relacionado con Windows
  • Últimamente los fabricantes se están moviendo a un modelo donde levantan un servidor web local y controlan el hardware desde el navegador, y suena como una idea terrible desde el punto de vista de seguridad

• Yo bloqueo todo el tráfico HTTP
  No solo AMD: Gigabyte, ASUS y otros también hacen que las actualizaciones automáticas fallen si no hay acceso HTTP
  Este hilo relacionado en Reddit también trata el problema
  Las solicitudes HTTP sin cifrar implican una filtración de privacidad y un posible vector de ataque MitM
  La pila TLS es un objetivo mucho más difícil de atacar

  • Si el payload está firmado, el nivel de confianza es parecido con HTTP o HTTPS
    Al final estás confiando en el código cliente de verificación de firmas, así que no es muy distinto de confiar en GPG
  • ¿Pero entonces no se rompen las consultas de CRL u OCSP?
  • Muchos repositorios de paquetes de Linux todavía usan solo HTTP
    Es conveniente para rastrear las versiones de paquetes instaladas, pero da mala espina desde el punto de vista de seguridad

• Esto es un problema realmente grave
  Se puede lograr ejecución arbitraria de código usando redirecciones HTTP, y este programa está instalado en muchísimas PCs
  Bastaría con abrir un hotspot Wi‑Fi en un aeropuerto para atacar de inmediato a usuarios de gráficos ATI

  • En mi país, si haces eso te arrestan
    O sea, la ley termina siendo la única medida de prevención
  • Claro que está mal, pero esto solo funciona cuando hay una actualización disponible
    Es decir, solo aplica si estás conectado a un hotspot riesgoso sin VPN, AMD publicó una actualización recientemente y se ejecuta el programador de tareas
  • ¿Quién se conectaría al hotspot de un desconocido?
    Pero si el ISP local es malicioso, el ataque es mucho más fácil
  • Yo uso las actualizaciones automáticas desactivadas
    Desde la época de Win98 pienso que las actualizaciones automáticas son la función más tonta

• Basta con envenenar DNS una sola vez para que el ataque sea posible
  Por ejemplo, si hackean el router y devuelve una IP incorrecta, se puede inyectar un binario malicioso en el tráfico HTTP
  HTTPS pasa intacto, pero HTTP es vulnerable
  Quien siga usando la contraseña de administrador por defecto debería cambiarla ya mismo
  Un atacante también puede hacer lo mismo con DHCP spoofing o con un Wi‑Fi falso

  • Hacer spoofing del SSID o jamming de la señal para conectar a los usuarios a un Wi‑Fi malicioso es muy fácil
  • El ataque también es posible simplemente respondiendo primero a la consulta DNS

• Cuesta entender que AMD haya rechazado esto diciendo que está fuera del alcance del bug bounty
  Perder aunque sea un cliente ya saldría más caro que la recompensa, así que usar el alcance definido en un documento como excusa para ignorar la seguridad envía una señal equivocada
  Esa actitud hará que los hackers dejen de reportarle cosas a AMD en el futuro

  • De hecho, a AMD ya le habían señalado este problema varias veces
    Así que incluso si estuviera dentro del alcance, hasta sería raro que pagaran una recompensa

• No es un simple error, sino un fallo del sistema de reportes de seguridad
  Está al nivel de que los departamentos de seguridad de grandes empresas deberían debatir si prohíben el hardware de AMD o su app de actualizaciones
  Si estuviera registrado como CVE, sería un incidente digno de salir en las noticias
  Un atacante podría vigilar tráfico HTTP desde una red Wi‑Fi pública o desde un ISP e infectar ejecutables

  • Cualquiera puede solicitar un CVE, así que quizá ese termine siendo el único camino para lograr una corrección

• AMD no dijo que esto no fuera una vulnerabilidad, solo dijo que está fuera del alcance del bug bounty

  • Pero ignorar una vulnerabilidad que permite escalada de privilegios remota no tiene defensa posible
    Para los atacantes no existe el concepto de “fuera del alcance”, pero AMD lo está tratando como política
    Eso es una clara política de irresponsabilidad en seguridad
  • Al final ya hasta dan ganas de decir que el documento de alcance de AMD es el verdadero bug

• Esta es una vulnerabilidad muy grave
  No debería minimizarse solo porque “requiere MitM”
  Internet en sí misma ya es un entorno MitM

  • En realidad ni siquiera hace falta un MitM
    Con un servidor DHCP malicioso que manipule DNS también se puede atacar

• Que AMD lo haya cerrado como “out of scope / won't fix” apenas un día después del reporte fue demasiado apresurado
  Tal vez solo significa que quedó fuera del canal de bug bounty, y no necesariamente que de verdad no vayan a corregirlo

• En mi PC, el terminal de AMD AutoUpdate aparece todos los días a medianoche y tengo que cerrarlo
  Ahora ya tengo una razón para bloquearlo por completo y volver a las actualizaciones manuales

  • ¡Ah, así que esa era esa ventana! Llevaba varios días tratando de averiguar qué era
  • Cuando usaba Windows, esa ventana de consola a veces se quedaba congelada durante horas
    Al final, si la cerraba, el controlador desaparecía en el siguiente arranque y tenía que reinstalarlo
    Era el peor programa de actualización automática que he usado