Un investigador de seguridad, conocido como mrbruh, descubrió un fallo que exponía a los usuarios de AMD a ataques de ejecución remota de código (RCE). La vulnerabilidad residía en el sistema de actualización automática del software de AMD, que descargaba archivos ejecutables a través de conexiones HTTP sin ningún tipo de verificación de autenticidad. Esto permitía a un atacante en la misma red —o incluso a nivel de ISP— interceptar las descargas y sustituirlas por malware.

El hallazgo

El 27 de enero de 2026, mrbruh rastreó un molesto cuadro de diálogo que aparecía periódicamente en su PC y terminó decompilando el ejecutable de AutoUpdate. Ahí descubrió que la URL de actualización se almacenaba en un archivo de configuración y, aunque el acceso al XML se hacía por HTTPS, las direcciones de descarga de los paquetes usaban HTTP plano. El programa no realizaba ninguna validación criptográfica de los archivos descargados antes de ejecutarlos.

Del rechazo al parche, 124 días después

El investigador reportó la vulnerabilidad el 6 de febrero de 2026 a través del programa de bug bounty de AMD, gestionado por Intigriti. Ese mismo día fue cerrada como «fuera de alcance», ya que los términos excluían los ataques man-in-the-middle. Mrbruh publicó un blog explicando el fallo, y al día siguiente la historia explotó en Hacker News. Entonces AMD dio marcha atrás: su equipo PSIRT contactó al investigador y le pidió que retirara el artículo hasta que pudieran solucionar el problema. El investigador accedió, aunque luego consideró que fue un error.

AMD emitió un CVE y prometió una corrección, pero solicitó un embargo más largo de lo habitual, alegando que múltiples herramientas estaban afectadas. El proceso se alargó: pasaron 69 días adicionales sin novedades. Mrbruh tuvo que presionar para obtener respuestas, y solo dos días antes del fin del embargo —fijado para el 9 de junio— AMD le explicó la solución. En total, desde la divulgación inicial hasta el parche transcurrieron 124 días, muy por encima de los 90 días que marca el estándar de la industria.

AMD se negó a pagar la recompensa. El investigador estima que, de haber estado dentro del alcance, el bug habría valido unos 10.000 dólares. La compañía solo ofreció reconocimiento y la asignación de un CVE.

La solución (y sus limitaciones)

Según AMD, en Ryzen Master se eliminó la función de actualización automática del instalador y se trasladó a la capa de aplicación, donde todas las comunicaciones ahora usan HTTPS y se aplica verificación de firmas. Sin embargo, mrbruh comprobó que lo segundo no es cierto: el único control de integridad que se realiza es una comprobación CRC-32, que no es criptográficamente segura. La verificación de firmas prometida no se implementó.

Un círculo vicioso

El escenario tiene una ironía adicional. El actualizador automático de AMD tiene otro fallo independiente: cuando intenta acceder a la lista de paquetes, una redirección del dominio (de ati.com a drivers.amd.com) provoca que el programa se cuelgue o se bloquee. Esto significa que, para corregir la vulnerabilidad, el usuario necesitaría actualizar el actualizador, pero el actualizador no puede actualizarse a sí mismo. Un callejón sin salida.

¿Qué deben hacer los usuarios?

El investigador recomienda desinstalar por completo todo el software AMD y descargar las versiones más recientes directamente desde el sitio web oficial. AMD publicó un aviso de seguridad (CVE) el 12 de junio de 2026 con los detalles del fallo y las acciones tomadas. Mientras tanto, los equipos con software AMD instalado siguen expuestos si no se aplica la actualización manualmente.