Google Cloud has warned customers running virtual machines on AMD Turin processors that three CPU side-channel flaws could let an attacker infer sensitive data from other processes, or from the operating system kernel, inside the same virtual machine. The company said it has already applied mitigations that protect against attacks between separate virtual machines and between a virtual machine and its host, but closing the remaining gap inside a guest will require action from customers.
Turin is the code name for AMD's fifth-generation EPYC processors, built on the Zen 5 architecture. On Google Cloud, the affected machine series are C4D, N4D, H4D, Z4D and G4, including bare-metal instances in the C4D and Z4D series. Google rates the overall issue as medium severity, and neither Google nor AMD reports any evidence of exploitation. As of November 12, none of the three flaws appears in the Known Exploited Vulnerabilities catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency.
All three flaws belong to a family known as Transient Scheduler Attacks, or TSA. Two of them, TSA-SQ, tracked as CVE-2024-36350, and TSA-L1, tracked as CVE-2024-36357, were first disclosed on July 8, 2025, for earlier generations of EPYC processors. AMD now says its Zen 5 processors are impacted differently from previously characterized processors, correcting an earlier position that Zen 5 was not vulnerable to those two variants. The third flaw is new. Tracked as CVE-2026-0004 and called TSA-Fill by the Xen Project, it may let an attacker who can run code on a system infer information held in the processor's Level 1 data cache.
AMD classifies all three as local attacks with high attack complexity that require only low privileges, according to its Zen 5 bulletin and its advisory for CVE-2026-0004. That matters most where untrusted code may share a core with a sensitive workload.
Google's security bulletin sets out different steps by service. For virtual machines, customers should install their operating system vendor's fix when it ships. Starting this week, Google will update the CPU information that virtual machines report, so that a patched guest kernel can switch on its mitigations. Once that update reaches a virtual machine, customers must stop and start the instance. Rebooting the guest operating system alone is not enough, Google stressed. Operators of C4D and Z4D bare-metal instances who run their own operating system or hypervisor should apply their vendor's fixes when available, and the same CPU information update applies to hypervisors running inside a virtual machine. For Google Kubernetes Engine, updated node images for Turin-based bare-metal instances are planned, but the bulletin did not yet list them as available. Cloud Run customers need to take no action.
Fixes are already moving through the open-source stack. A kernel commit that mitigates TSA on Zen 5, including the new variant, is in the Linux kernel source tree, and Debian has fixed CVE-2026-0004 in its unstable branch while its stable releases remain listed as vulnerable. The Xen Project has published hypervisor patches, and it notes that microcode for the Zen 5 TSA flaws has been in linux-firmware since September 23. For Turin servers running on a customer's own hardware, AMD says both platform firmware and operating system updates are needed for a full mitigation, and it warns that the mitigation may affect performance, so administrators should weigh the risk against their own workloads.
Photo: Aerial view of the Google Data Center in Council Bluffs, Iowa, by Chad Davis, CC BY 2.0, via Wikimedia Commons.