Tres vulnerabilidades en los chips EPYC Zen 5 podrían permitir extraer información de otros procesos. Google exige actualizar el sistema operativo y detener y arrancar determinadas máquinas virtuales.
La seguridad de la infraestructura en la nube vuelve a estar bajo examen. Google Cloud ha advertido de tres vulnerabilidades en los procesadores AMD EPYC de quinta generación, conocidos por su nombre en clave como Turin, que podrían permitir a un atacante obtener información de otros procesos o del núcleo del sistema operativo.
El aviso, publicado el 10 de noviembre de 2026, afecta a varias familias de máquinas virtuales de Google Cloud. La compañía asegura que ya ha aplicado medidas para proteger la comunicación entre máquinas virtuales y entre estas y el equipo anfitrión. Sin embargo, todavía es necesario actuar para cerrar el riesgo dentro de cada máquina afectada.
La recomendación no consiste simplemente en reiniciar el sistema. Google exige instalar las actualizaciones de seguridad correspondientes y después detener y volver a arrancar la máquina virtual. Un reinicio convencional del sistema operativo no es suficiente para activar todas las protecciones.
El incidente vuelve a poner sobre la mesa una cuestión esencial para las empresas: la seguridad de los servicios en la nube depende tanto de los proveedores como de las actualizaciones que deben aplicar sus clientes.
Tres vulnerabilidades TSA amenazan la confidencialidad de los datos
Las tres vulnerabilidades pertenecen a una categoría denominada Transient Scheduler Attacks (TSA), o ataques al planificador transitorio.
Se trata de técnicas de canal lateral que aprovechan determinados comportamientos internos del procesador para inferir información que, en condiciones normales, debería permanecer aislada entre procesos o niveles de privilegio.
No significa que cualquier usuario de Internet pueda conectarse a un servidor y leer directamente sus datos. El escenario descrito por los fabricantes requiere que el atacante tenga capacidad para ejecutar código en el sistema y que se den determinadas condiciones técnicas, entre ellas la posibilidad de compartir recursos del núcleo del procesador.
Los tres identificadores afectados son:
- CVE-2024-36350 (TSA-SQ): puede permitir inferir información procedente de operaciones de almacenamiento anteriores.
- CVE-2024-36357 (TSA-L1): puede facilitar la inferencia de datos presentes en la caché de datos L1.
- CVE-2026-0004 (TSA-Fill): una vulnerabilidad adicional que puede permitir inferir información de la caché L1 de datos del procesador.
Las dos primeras vulnerabilidades ya se habían comunicado en julio de 2025 para generaciones anteriores de procesadores EPYC. Sin embargo, AMD ha determinado que los chips basados en Zen 5 presentan un comportamiento diferente al de las generaciones previamente analizadas y necesitan medidas adicionales.
La tercera vulnerabilidad, CVE-2026-0004, se ha incorporado a este conjunto de problemas de seguridad en los avisos publicados por AMD en noviembre de 2026.
Qué procesadores y máquinas virtuales están afectados
El nombre Turin identifica a la quinta generación de procesadores AMD EPYC, diseñados para servidores y centros de datos. Estos chips están destinados a cargas de trabajo empresariales, servicios de computación en la nube, virtualización y procesamiento intensivo.
El boletín de Google identifica cinco familias de máquinas de Compute Engine afectadas:
- C4D.
- N4D.
- H4D.
- Z4D.
- G4.
También se incluyen las instancias bare metal de las familias C4D y Z4D, que ofrecen acceso a hardware físico sin la capa de virtualización convencional.
La advertencia no implica que todos los ordenadores que utilizan procesadores AMD estén afectados. El aviso de Google se refiere a las configuraciones concretas de su infraestructura que emplean los procesadores Turin.
AMD, por su parte, ha publicado boletines específicos para los productos afectados y recomienda consultar las actualizaciones de firmware y sistema operativo correspondientes a cada plataforma.
Google ya ha protegido la comunicación entre máquinas virtuales
Uno de los elementos más importantes del comunicado es que Google asegura haber aplicado mitigaciones para impedir ataques entre máquinas virtuales y entre una máquina virtual y el equipo anfitrión.
Esto significa que la compañía ha abordado una parte relevante del riesgo asociado a la separación entre clientes que comparten infraestructura física.
Sin embargo, queda otro escenario: los ataques dentro de una misma máquina virtual.
En determinadas circunstancias, un proceso malicioso que ya se esté ejecutando en el mismo entorno puede intentar inferir información de otros procesos o del núcleo del sistema operativo mediante los mecanismos internos del procesador.
Esta distinción es fundamental para comprender el alcance real del problema. No se ha anunciado una vulnerabilidad que permita a cualquier usuario externo saltarse automáticamente las barreras de Google Cloud. El riesgo descrito requiere condiciones de ejecución y acceso local mucho más concretas.
Aun así, para una empresa que ejecuta varias aplicaciones o servicios dentro de una misma máquina virtual, la posibilidad de que un proceso obtenga información de otro representa un problema de confidencialidad que no debe ignorarse.
La instrucción de Google: actualizar y detener la máquina virtual
El boletín de seguridad GCP-2026-081, publicado por Google el 10 de noviembre, establece medidas distintas según el tipo de infraestructura utilizada.
Máquinas virtuales de Compute Engine
Los administradores deben instalar las actualizaciones de seguridad del sistema operativo invitado cuando estén disponibles.
Google también está modificando la información sobre las características de la CPU que reciben las máquinas virtuales. El objetivo es que los núcleos de los sistemas operativos actualizados puedan activar las mitigaciones correspondientes.
Una vez que el cambio llegue a la máquina virtual, el administrador deberá detenerla y volver a iniciarla.
Google insiste en que un simple reinicio del sistema operativo no basta. La operación debe realizarse desde el mecanismo de gestión de la máquina virtual para que se apliquen los cambios necesarios en la configuración que presenta el procesador.
Servidores bare metal
Las empresas que utilizan instancias bare metal C4D o Z4D con su propio sistema operativo o hipervisor deben instalar las actualizaciones que publiquen sus respectivos proveedores.
En estos casos, la responsabilidad de aplicar las medidas correctivas depende de la configuración y del software que gestione el servidor.
Virtualización anidada
Las organizaciones que ejecutan un hipervisor dentro de una máquina virtual también deben aplicar las actualizaciones del sistema operativo invitado y completar el ciclo de parada y arranque cuando Google haya actualizado la información de la CPU.
Google Kubernetes Engine
Google ha anunciado que pondrá a disposición imágenes actualizadas de nodos para las instancias bare metal basadas en Turin. Los administradores deberán actualizar los nodos para incorporar los cambios.
En el momento del boletín, la compañía todavía no indicaba que esas imágenes estuvieran disponibles.
Cloud Run
Para los usuarios de Cloud Run, Google señala que no es necesario realizar ninguna acción específica.
AMD confirma que hacen falta actualizaciones de firmware y del sistema operativo
La respuesta de Google no es la única parte de la solución. AMD también ha publicado dos boletines de seguridad específicos para documentar las vulnerabilidades y las medidas necesarias.
El primero es el aviso AMD-SB-7073, dedicado a los ataques TSA en procesadores Zen 5. El documento explica que las generaciones Zen 5 presentan características distintas a las de los procesadores analizados anteriormente y que es necesario incorporar medidas adicionales.
AMD señala que la mitigación completa de las vulnerabilidades aplicables requiere dos elementos:
- Actualizaciones del firmware Platform Initialization (PI) de la plataforma.
- Actualizaciones del sistema operativo para activar las protecciones correspondientes.
El segundo documento es el boletín AMD-SB-3055, que aborda específicamente la vulnerabilidad CVE-2026-0004.
En el caso de los procesadores EPYC 8005 y 9005, AMD identifica la versión TurinPI_1.0.0.B como actualización de firmware correspondiente a esta vulnerabilidad. La compañía indica que los fabricantes de equipos deben distribuir las versiones adecuadas para cada producto.
Por ello, los administradores de servidores propios no deben limitarse a actualizar Linux o Windows: también deben comprobar si el fabricante del equipo ha publicado una actualización de BIOS o firmware compatible.
Qué gravedad tienen los fallos y existe evidencia de ataques
Google clasifica el problema con una gravedad media. AMD asigna puntuaciones CVSS de 5,6 a CVE-2024-36350 y CVE-2024-36357, y de 5,7 a CVE-2026-0004.
Estas puntuaciones reflejan que las vulnerabilidades pueden comprometer la confidencialidad de la información, pero también que su explotación presenta limitaciones técnicas.
Los tres fallos se describen como ataques locales, con una complejidad elevada y necesidad de privilegios bajos. Esto no elimina el riesgo, pero sí permite diferenciarlo de una vulnerabilidad remota que pueda explotarse directamente desde Internet sin acceso previo al sistema.
Además, en los avisos consultados no se comunica explotación confirmada de estas vulnerabilidades. Tampoco figuraban en el catálogo KEV de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA), que recoge vulnerabilidades con evidencias de explotación conocida.
Es importante no confundir la existencia de una vulnerabilidad con la confirmación de un ataque. Los fabricantes han publicado medidas preventivas porque el riesgo técnico existe, no porque hayan anunciado una campaña de intrusión en curso.
Las actualizaciones pueden afectar al rendimiento
La aplicación de medidas de seguridad a nivel de procesador puede tener consecuencias sobre el rendimiento, especialmente en cargas de trabajo que dependen de operaciones intensivas de memoria y ejecución.
AMD advierte de que los administradores deben valorar el impacto de las mitigaciones en sus sistemas y cargas de trabajo.
Esta circunstancia obliga a las empresas a equilibrar dos necesidades: proteger la información y mantener la disponibilidad de sus servicios.
En entornos críticos, la actualización debe planificarse con especial cuidado. Una parada y un arranque de máquinas virtuales pueden afectar a aplicaciones empresariales, bases de datos y servicios que dependen de ellas.
Por eso, los equipos de sistemas deberían comprobar primero qué instancias utilizan procesadores Turin, identificar las cargas de trabajo afectadas y coordinar las actualizaciones con sus proveedores de sistemas operativos y aplicaciones.
La seguridad de la nube también depende de los clientes
El aviso de Google deja una conclusión relevante: contratar infraestructura en la nube no elimina la responsabilidad de mantener los sistemas actualizados.
El proveedor puede proteger el hardware, aplicar mitigaciones en el hipervisor y corregir vulnerabilidades de su infraestructura. Pero las empresas siguen teniendo obligaciones sobre los sistemas operativos, las aplicaciones y los permisos que utilizan dentro de sus máquinas virtuales.
En este caso, Google ha actuado sobre las barreras entre máquinas virtuales y entre estas y el anfitrión. Sin embargo, el cierre del riesgo dentro de cada máquina requiere también la intervención del cliente.
Para las organizaciones que gestionan datos sensibles, el episodio refuerza la importancia de mantener inventarios de hardware, seguir los boletines de seguridad y disponer de procedimientos de actualización y recuperación.
La nube no es una garantía automática de invulnerabilidad. Su seguridad depende de una cadena de responsabilidades en la que intervienen el fabricante del procesador, el proveedor de infraestructura, los desarrolladores del sistema operativo y los administradores de cada servicio.
Las vulnerabilidades de AMD Turin no demuestran que Google Cloud haya sufrido una filtración de datos ni que los clientes estén siendo atacados. Sí evidencian que incluso los centros de datos más avanzados necesitan correcciones coordinadas y que dejar una actualización pendiente puede prolongar innecesariamente la exposición.


