Una vulnerabilidad crítica que AMD decidió no solucionar
Un investigador de seguridad ha revelado una vulnerabilidad de ejecución remota de código (RCE) en el software AutoUpdate de AMD que podría permitir a atacantes interceptar y modificar actualizaciones ejecutables. Lo más preocupante: AMD consideró la vulnerabilidad fuera de alcance y decidió no corregirla, lo que expone a millones de usuarios a potenciales ataques de cadena de suministro.
Este caso plantea preguntas cruciales para founders y equipos tecnológicos: ¿hasta qué punto podemos confiar en los procesos de actualización de software de terceros? ¿Qué responsabilidad tienen los fabricantes cuando deciden no solucionar vulnerabilidades conocidas?
El problema técnico: HTTP sin validación de certificados
La vulnerabilidad descubierta en AutoUpdate de AMD radica en el uso de URLs HTTP sin la debida validación de certificados para descargar actualizaciones ejecutables. En términos prácticos, esto significa que:
- Las actualizaciones se transmiten sin cifrado seguro (HTTP en lugar de HTTPS)
- No existe validación robusta de certificados digitales que autentique la procedencia del archivo
- Un atacante posicionado en la red (ataque man-in-the-middle) podría interceptar la comunicación
- El atacante podría reemplazar la actualización legítima con código malicioso
- El sistema ejecutaría el código comprometido con privilegios elevados
Este tipo de vulnerabilidad en software de actualización es especialmente peligrosa porque los usuarios confían implícitamente en estos procesos. Cuando tu sistema te indica que hay una actualización disponible de AMD, asumes que es legítima y la instalas sin cuestionarla.
Investigación y reporte: cuando la transparencia no es suficiente
El investigador de seguridad MrBruh —conocido por descubrir vulnerabilidades similares en otros fabricantes— realizó una investigación exhaustiva del proceso de actualización de AMD. Tras documentar la vulnerabilidad, siguió el proceso estándar de divulgación responsable: reportó el hallazgo directamente a AMD antes de hacerlo público.
La respuesta de AMD fue inesperada: la empresa consideró la vulnerabilidad fuera del alcance de su programa de seguridad y optó por no solucionarla. Esta decisión genera un precedente preocupante en la industria, donde fabricantes de hardware pueden determinar unilateralmente qué vulnerabilidades merecen atención y cuáles no.
Contexto: un patrón en la industria
Esta no es la primera vez que se descubren vulnerabilidades en software de actualización automática de fabricantes de hardware. Recientemente, ASUS DriverHub enfrentó un problema similar (CVE-2025-3462 y CVE-2025-3463), también descubierto por MrBruh, que involucraba validación inadecuada de origen y verificación débil de certificados. En ese caso, ASUS sí corrigió la vulnerabilidad tras la divulgación.
La diferencia de respuesta entre fabricantes evidencia la falta de estándares consistentes en la industria sobre cómo manejar vulnerabilidades en componentes considerados ‘auxiliares’ al producto principal.
Implicaciones para startups tecnológicas
Para founders y equipos de desarrollo, este caso ofrece lecciones importantes sobre seguridad en la cadena de suministro:
1. Las dependencias de terceros son vectores de ataque
Cada componente de software que instalas en tu infraestructura —drivers, utilidades de actualización, herramientas de monitoreo— representa un potencial punto de entrada para atacantes. Las startups deben implementar políticas de evaluación de riesgos para todas las dependencias, no solo las que están directamente en su código.
2. La confianza debe ser verificable
El modelo de ‘confiar por defecto’ en software de fabricantes reconocidos ya no es sostenible. Implementa controles como:
- Monitoreo de tráfico de red saliente desde herramientas de actualización
- Políticas de firewall que restrinjan comunicaciones no cifradas
- Verificación de hash/firmas digitales de actualizaciones antes de ejecutarlas
- Ambientes de prueba aislados para validar actualizaciones críticas
3. El riesgo reputacional es real
Si tu startup sufre una brecha de seguridad debido a una vulnerabilidad conocida en software de terceros, tus clientes no distinguirán responsabilidades. La confianza perdida afecta tu marca independientemente de quién fue técnicamente responsable del fallo.
¿Qué pueden hacer los usuarios y empresas?
Ante la decisión de AMD de no solucionar esta vulnerabilidad, las opciones de mitigación son limitadas pero importantes:
- Desactivar AutoUpdate de AMD y realizar actualizaciones manualmente descargando drivers directamente desde el sitio oficial con HTTPS
- Implementar segmentación de red para que sistemas críticos no compartan redes con estaciones de trabajo que ejecuten software potencialmente vulnerable
- Usar soluciones de detección de intrusiones (IDS) que identifiquen patrones anómalos en descargas de actualizaciones
- Mantener registros de auditoría de todas las actualizaciones de software instaladas para facilitar investigación forense si ocurre un incidente
- Evaluar proveedores alternativos cuyas políticas de seguridad estén más alineadas con las necesidades de tu organización
El debate más amplio: responsabilidad corporativa en ciberseguridad
Este caso abre un debate necesario sobre la responsabilidad de los fabricantes de hardware y software. Cuando una empresa decide que una vulnerabilidad está ‘fuera de alcance’, ¿quién protege a los usuarios finales?
En el ecosistema de startups, donde la agilidad y la innovación son prioritarias, la seguridad no puede ser un pensamiento posterior. Los founders deben exigir a sus proveedores los mismos estándares de seguridad que implementan internamente. La presión del mercado es a menudo más efectiva que los reportes de vulnerabilidades para cambiar comportamientos corporativos.
Las empresas que ignoran vulnerabilidades conocidas enfrentan riesgos regulatorios crecientes, especialmente en Europa con GDPR y la próxima directiva NIS2, que impone obligaciones estrictas sobre seguridad de cadena de suministro digital.
Conclusión
La vulnerabilidad RCE en AutoUpdate de AMD y la decisión de la empresa de no solucionarla representa más que un problema técnico aislado: es un indicador de cómo algunas corporaciones priorizan conveniencia operativa sobre seguridad de usuarios. Para el ecosistema de startups tecnológicas, este caso refuerza la necesidad de adoptar una postura de seguridad Zero Trust, donde cada componente del stack tecnológico debe ganarse la confianza continuamente.
Los founders deben recordar que en seguridad informática, el eslabón más débil define la fortaleza de toda la cadena. Una startup puede tener el código más seguro del mundo, pero si un simple proceso de actualización de drivers puede comprometer todo el sistema, la inversión en seguridad habrá sido insuficiente.
La transparencia del investigador MrBruh al hacer pública esta información es invaluable para la comunidad tecnológica. Solo cuando las vulnerabilidades se visibilizan, las empresas sienten presión real para actuar. Como ecosistema, debemos apoyar la divulgación responsable y exigir que los fabricantes tomen la seguridad tan en serio como sus usuarios lo hacen.
¿Quieres mantenerte al día con las últimas amenazas de seguridad y mejores prácticas de ciberseguridad para tu startup? Únete gratis a Ecosistema Startup y conecta con founders que priorizan la seguridad en sus operaciones.
Fuentes
- https://mrbruh.com/amd/ (fuente original)
- https://hoploninfosec.com/asus-driverhub-flaw
- https://www.pcgamer.com/hardware/the-asus-tool-pc-gamers-use-to-update-drivers-fix-bugs-and-improve-security-turns-out-to-have-a-bit-of-a-security-issue-itself/
- https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6018.html
