Google Cloud says it has protected the boundaries between virtual machines against three newly detailed AMD Turin processor vulnerabilities. That does not mean every application inside those machines is protected. Its 10 November bulletin leaves guest operating-system fixes as a separate responsibility, exposing a familiar weakness in cloud security reporting: a provider can finish its part while the customer's workload still needs attention.

The developments concern Transient Scheduler Attacks, or TSA, on fifth-generation AMD EPYC processors. They are information-disclosure risks involving CPU execution, rather than a newly announced remote takeover of Google Cloud. The practical question is which security boundary a mitigation covers, not whether a service can be described simply as patched.

Two existing CVEs acquire a new hardware scope

AMD's Zen 5 security bulletin, AMD-SB-7073, revises the understanding of two existing vulnerabilities. CVE-2024-36350, called TSA-SQ, concerns inference of information from previous stores. CVE-2024-36357, TSA-L1, concerns data in the first-level data cache. AMD says subsequent investigation found that Zen 5 processors are affected differently from previously characterized processors.

Old CVE numbers therefore do not make this a recycled warning. The hardware assessment changed. AMD identifies potential leakage across privilege boundaries and says affected platforms require firmware and operating-system updates for full mitigation. A fleet inventory based on an earlier conclusion that Zen 5 was unaffected can now produce the wrong answer.

A separate AMD bulletin, AMD-SB-3055, covers CVE-2026-0004. It describes a transient-execution flaw that could expose L1 data-cache information to an attacker able to execute code on the system. Its EPYC product table includes the 8005 and 9005 series and identifies both firmware and OS dependencies. Firmware package dates in that table precede the bulletin's initial publication on 10 November 2026; those dates should not be mistaken for the public disclosure date.

Local execution is an important limit

These advisories do not establish that an arbitrary visitor to a website can read the server's memory. AMD's scoring describes local attacks with high complexity. A hosting threat assessment must account for whether an adversary can execute code and which resources or privilege boundaries that code can reach.

For a provider that deliberately accepts customer workloads, local execution is part of the service it sells. For an application owner running only trusted code, the exposure is different. Neither situation justifies treating every AMD machine as compromised, nor dismissing the issue because it is not a conventional network exploit.

The hardware brand and the VM allocation are also different facts. Our shared versus dedicated vCPU analysis explains scheduling and allocation terms. A performance-oriented promise of dedicated CPU time should not be read as evidence that the relevant firmware and guest protections are present.

Google separates the host boundary from the guest boundary

Google's GCP-2026-081 bulletin names C4D, N4D, H4D, Z4D and G4, including C4D and Z4D bare-metal instances.

Patched guest kernels depend on updated CPU information. Google requires a VM stop and start after that update reaches the instance; a guest reboot is insufficient. Maintenance planning therefore involves more than an OS package.

Cloud Run requires no customer action. Updated GKE node images for Turin-based bare-metal instances are described as forthcoming, not already available. These statements concern Google's services, not unrelated providers.

Xen shows why migration is not always completion

The Xen project's XSA-525 advisory, released on 10 November, independently documents the revised Zen 5 assessment and the additional TSA variant. It warns of possible data inference across contexts, including other guests, on affected systems.

Xen describes a resolution involving updated microcode and hypervisor patches. It also says VMs need a reboot, rather than migration alone, to receive the revised CPU safety status. Google's stop-and-start requirement and Xen's guest-reboot requirement belong to different implementations; substituting one provider's lifecycle rule for another would be unsafe reasoning.

For tenants, a useful provider statement identifies the affected allocation, the boundary already protected and any remaining guest dependency. For operators, completion means matching that statement to the actual platform and workload state. A green host-maintenance dashboard cannot, by itself, establish that every guest has accepted the revised CPU information or activated its own protections.