Investigadores del ETH Zürich revelaron en abril una vulnerabilidad de software puro que socava silenciosamente las protecciones de computación confidencial SEV-SNP en los EPYC de AMD, dándole a un host cloud malicioso acceso completo de lectura y escritura sobre memoria de máquinas virtuales supuestamente protegidas. La técnica, bautizada Fabricked, explota fallas en cómo el interconector Infinity Fabric del procesador maneja el ruteo de memoria durante el arranque, y permite además forjar los reportes criptográficos de atestación con los que el inquilino verifica que su entorno no fue alterado.

El trabajo fue presentado en USENIX Security 2026. Los autores describen el exploit como totalmente determinístico, con tasa de éxito del 100%, sin necesidad de acceso físico y sin ejecutar código dentro de la VM víctima.

¿Qué se supone que protege SEV-SNP?

La computación confidencial existe para resolver un problema fundamental de confianza en la nube: los inquilinos no tienen forma de verificar que el proveedor no está accediendo a sus datos. AMD SEV-SNP aborda esto creando máquinas virtuales confidenciales (CVM) con memoria cifrada y controlada por un procesador de seguridad dedicado en el chip, llamado PSP.

Para hacer cumplir esos límites, SEV-SNP depende de una estructura llamada Reverse Map Table (RMP): una tabla por página, guardada en memoria, que el PSP inicializa de manera segura durante el boot. La atestación —el mecanismo por el que el inquilino verifica criptográficamente que su entorno es genuino— depende de que esa cadena se mantenga. Es exactamente eso lo que Fabricked rompe.

¿Cómo se llega al exploit a través del Infinity Fabric?

La técnica apunta a un componente al que casi nadie le presta atención: el Infinity Fabric, el interconector interno entre chiplets que AMD usa para rutear tráfico de memoria entre los núcleos del CPU, los controladores de memoria y los periféricos. Como las configuraciones de plataforma varían según el hardware, partes del Infinity Fabric deben configurarse en cada arranque desde el firmware del motherboard (la UEFI). En el propio modelo de amenazas de AMD, esa UEFI está explícitamente clasificada como no confiable, porque la controla el proveedor cloud.

Los investigadores encontraron que la UEFI es responsable de emitir dos llamadas a la API del PSP que bloquean los registros de configuración del Infinity Fabric después de la inicialización. Una UEFI maliciosa puede simplemente omitirlas, dejando el Data Fabric —la capa de ruteo de memoria dentro del Infinity Fabric— escribible por el atacante incluso después de que SEV-SNP se activó.

A partir de ahí, el exploit aprovecha una segunda falla más sutil. Las solicitudes de memoria del PSP eran chequeadas contra reglas de ruteo MMIO —reglas normalmente reservadas para comunicación con dispositivos de hardware— antes de aplicar las reglas estándar de ruteo a DRAM. Al configurar esos mapeos MMIO para que sombreen la región de memoria del RMP, el atacante hace que las escrituras de inicialización del PSP se descarten silenciosamente. El RMP nunca se inicializa correctamente, pero SEV-SNP reporta inicialización exitosa de todas formas. La plataforma cree que el sistema es seguro cuando no lo es.

Con un RMP no inicializado y bajo control del atacante, el hipervisor puede leer y escribir memoria arbitraria de la CVM. Los autores demostraron dos exploits concretos: habilitar modo debug en una CVM productiva después de la atestación (lo que le da al hipervisor capacidad de descifrar memoria arbitraria de la VM, sin que el guest lo detecte), y forjar reportes de atestación al por mayor, permitiendo que una imagen maliciosa pase como una de confianza.

¿Qué procesadores están afectados y cómo se parcha?

Los investigadores confirmaron el exploit sobre AMD Zen 5 EPYC. El advisory de AMD también lista actualizaciones de firmware para Zen 3 y Zen 4, lo que sugiere exposición más amplia entre generaciones. AMD reconoció la vulnerabilidad tras la divulgación responsable de ETH Zürich en agosto de 2025, le asignó CVE-2025-54510 y publicó la guía de seguridad AMD-SB-3034 cuando se levantó el embargo en abril de 2026.

Las organizaciones que corren cargas confidenciales sobre EPYC deben verificar con su proveedor cloud que el firmware actualizado ya esté desplegado. Los usuarios domésticos y las cargas cloud estándar que no dependen de SEV-SNP no están afectados.

¿Por qué importa para Chile y LATAM?

El sector financiero chileno y la administración pública vienen migrando cargas sensibles a clouds que ofrecen confidential computing como respaldo de cumplimiento (la Ley Marco de Ciberseguridad 21.663 exige cuidados específicos sobre datos en tránsito y reposo). Si el sustrato técnico de esa confianza se rompe, cualquier auditoría que se apoyó en el sello "EPYC con SEV-SNP" tiene que rehacerse con el firmware actualizado. Los proveedores hyperscale (AWS Nitro Enclaves, Azure Confidential VMs, GCP Confidential Computing) suelen parchar primero, pero las nubes locales y los privados on-prem que corren EPYC deben verificar versión de UEFI y firmware del PSP.

Publicado originalmente en Tom's Hardware.