Google Cloud has disclosed that three side-channel vulnerabilities in AMD's Turin server processors could allow an attacker running code inside a virtual machine to infer data belonging to other processes — or even the guest kernel — on the same physical core. The warning, reported by The Hacker News, applies to customers running workloads on Google Cloud instances backed by the affected EPYC hardware.

What Google Cloud disclosed

According to the advisory, the three flaws are CPU side-channel issues rather than a conventional memory-corruption bug. That distinction matters: there is no single patch that closes the hole at the application layer. Instead, protection depends on a combination of hypervisor-level mitigations, which Google says it has already deployed, and a guest operating system update that customers must apply themselves.

Google Cloud stated that it has already applied mitigations covering attacks between separate VMs and between VMs and the host. Those are the boundaries cloud providers typically treat as the highest priority, since a cross-tenant break would undermine the fundamental isolation model of public cloud infrastructure.

The residual risk sits inside the VM

The remaining exposure is intra-VM. Within a single virtual machine, the flaws may let an attacker who already has code executing on the same processor core infer information from other processes or from the guest kernel. In practice, that means the threat model is a multi-tenant or multi-process workload sharing a VM — for example, a container host, a CI runner executing untrusted code, or a server running co-located customer jobs.

Inference-based side channels do not hand an attacker a clean memory dump. They typically allow statistical recovery of secrets such as cryptographic keys or tokens over many observations, which makes them slow and probabilistic but still valuable in the right circumstances. The practical severity therefore depends heavily on what an organisation runs inside a single VM and how much it trusts the code sharing that environment.

Customers need to patch and restart

Google's guidance is straightforward but operationally disruptive: affected customers must update the guest operating system with the vendor-supplied mitigations and then stop and start the instance. A simple reboot is reportedly not sufficient — the instance must be fully stopped and started so the VM is rescheduled onto a host with the corrected configuration. Teams that treat reboots and stop-start cycles as routine maintenance should be fine; those with long-lived, stateful instances will need to plan a maintenance window.

That requirement is worth flagging to change-management and platform teams early. Stop-and-start operations can alter instance metadata such as ephemeral IP addresses and host placement, and they reset in-memory state on the guest. Applications that rely on instance identity or local caches should be validated afterwards.

Why this keeps happening

Microarchitectural side-channel research has been a recurring theme since the original Spectre and Meltdown disclosures, and AMD's EPYC line has been the subject of several advisories in recent years. Modern server CPUs rely on speculative execution, shared caches, and simultaneous multithreading — all of which create the timing signals that side-channel attacks exploit. Vendors respond with microcode and software mitigations, but each generation of silicon tends to introduce new surfaces for researchers to probe.

For defenders, the recurring lesson is that CPU-level isolation is not something an organisation can fully control on its own. In public cloud, the provider handles the hypervisor boundary; the customer remains responsible for the guest layer.

Recommended actions

  • Inventory affected instances. Identify Google Cloud VMs running on AMD Turin hardware and prioritise those hosting multi-tenant or untrusted workloads.
  • Apply guest OS updates promptly. Track the relevant AMD and OS vendor advisories for the microcode and kernel-side fixes.
  • Plan stop-start maintenance. Schedule the full stop and start, not just a reboot, and account for IP and placement changes.
  • Reduce intra-VM trust. Where feasible, avoid running mutually untrusted workloads on the same VM, and consider stronger isolation boundaries for CI runners and container hosts.
  • Watch for updates. Google Cloud has not framed this as a cross-tenant emergency, but the advisory is likely to be revised as more technical detail emerges.

The disclosure is a reminder that cloud security is a shared responsibility down to the silicon. Google has done its part at the hypervisor layer; the rest depends on customers patching their guests and restarting their instances.