Google Cloud has told customers running virtual machines on AMD Turin processors that they need three fixes, a guest patch and a restart. Turin is the code name for fifth-generation EPYC silicon.
The hypervisor layer is already handled. Google says it applied mitigations against cross-VM attacks and against VM-to-host attacks before the disclosure.
What remains is traffic inside a single virtual machine.
What an attacker on the same core sees
All three bugs belong to a family AMD calls transient scheduler attacks. An adversary who already has code running on the same processor core may be able to infer data belonging to a neighbouring process or to the guest kernel.
Two of them are not new. TSA-SQ, tracked as CVE-2024-36350, and TSA-L1, tracked as CVE-2024-36357, were published in July 2025 against earlier EPYC generations.
The third is fresh. CVE-2026-0004, which the Xen Project calls TSA-Fill, can expose contents of the L1 data cache. AMD now describes its Zen 5 parts, Turin included, as impacted differently from the processors it characterised previously.
Which instance types need action
The machine series listed by Google are C4D, N4D, H4D, Z4D and G4, along with bare-metal C4D and Z4D instances. Hosts updated their microcode on Google’s side, so the gap is the guest image.
For defenders, the practical checklist is short. Inventory anything on those shapes, confirm the kernel in each image carries the vendor patch, and plan the stop-and-start that applies it. Instances left running on an old kernel keep the exposure, and a live migration does not clear it.
Confidential-computing tenants should also revisit their threat model. Cross-core leakage inside a guest is exactly the class of risk a TEE does not cover when the operating system itself is the attacker’s foothold.
