Petronella.ai

AMD Turin CPU Flaws Risk Data Leaks Across VM Processes

November 12, 2026 · Cybersecurity
AMD Turin CPU Flaws Risk Data Leaks Across VM Processes

Three AMD Turin CPU flaws could let an attacker inside a virtual machine infer data from other processes on the same processor core, and Google Cloud says a guest OS patch plus a stop-and-start is required to close them.

Google Cloud disclosed the issue in a security bulletin this week, covered by The Hacker News, which reported the details of the advisory and the vendor responses that followed. The affected chips are fifth-generation AMD EPYC processors, code named Turin, which power several Google Cloud machine series used by businesses in regulated industries. Anyone running workloads on those series, or on Turin servers of their own, should care: the flaws are local side-channel attacks, meaning they require an attacker to already be able to run code on the system, but they can potentially cross privilege boundaries that organizations assume are hard lines.

Key Takeaways

What happened: the facts in detail

Google Cloud's advisory

Google Cloud warned this week that virtual machines running on AMD Turin processors need a guest operating system patch and a stop-and-start cycle to protect against three CPU side-channel flaws. The company stated it has already applied mitigations against attacks between VMs, and between VMs and the host. The residual risk is inside a single VM: the flaws may let an attacker who has code running on the same processor core infer data from other processes or from the kernel.

The affected machine series are C4D, N4D, H4D, Z4D, and G4, including bare-metal instances of C4D and Z4D. Turin is the code name for fifth-generation AMD EPYC processors.

The three flaws and their history

All three flaws are Transient Scheduler Attacks (TSA). Two of them, TSA-SQ (CVE-2024-36350) and TSA-L1 (CVE-2024-36357), were first disclosed on July 8, 2025, for earlier EPYC processors. At that time, Google gave customers on older Rome, Milan, and Genoa processors the same stop-and-start instruction in an earlier bulletin.

The third flaw, CVE-2026-0004, is new. According to AMD's advisory, a transient execution vulnerability in some AMD processors could allow an attacker with the ability to execute code on the system to infer data in the L1D cache, potentially resulting in leakage of sensitive information across privileged boundaries.

The Xen Project, which maintains the Xen hypervisor, calls the new flaw TSA-Fill. It also published a correction to an earlier statement: "AMD had previously said that Zen5 CPUs were not vulnerable to TSA-SQ and TSA-L1." AMD's own bulletin now reflects the change, stating that subsequent investigation determined AMD Zen 5 processors are impacted differently from previously characterized AMD processors.

Severity and exploitation status

Google rates the issue Medium. AMD's Zen 5 bulletin assigns both CVE-2024-36350 and CVE-2024-36357 a CVSS 3.1 base score of 5.6, with the vector AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, classified under CWE-421, exposure of sensitive information in shared microarchitectural structures during transient execution. The new CVE-2026-0004 advisory carries a CVSS 4.0 score of 5.7 with the vector AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. AMD encourages customers to calculate CVSS scores independently for their own systems, noting specific scores may change subject to implementation.

As of today, none of the three flaws is in the KEV catalog of exploited vulnerabilities kept by the U.S. Cybersecurity and Infrastructure Security Agency. Neither Google nor AMD reports any exploitation in its bulletins.

Who found it

AMD thanks Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos from Microsoft, and Flavien Solt from ETH Zurich for reporting these issues and engaging in coordinated vulnerability disclosure.

What vendors have shipped so far

A kernel commit that mitigates TSA on Zen 5, including the new variant, is in the Linux kernel source tree. As of today, Debian has fixed CVE-2026-0004 in its Linux kernel only in its unstable branch; its security tracker still lists the kernels in bookworm, trixie, and forky as vulnerable.

The Xen Project has published hypervisor patches in its Xen advisory and says microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23. AMD says it is releasing additional Platform Initialization (PI) firmware package updates and corresponding mitigations for affected Zen 5 products, and plans to release PI firmware versions to original equipment manufacturers on target dates listed in its bulletins; customers are directed to contact their OEM for the BIOS update specific to their products.

Google's bulletin lays out steps per service. For VMs, install the OS vendor's fix when it ships. Starting this week, Google will update the CPU information that VMs report, so a patched guest kernel can turn on its mitigations; after that update reaches a VM, stop and start it. For bare metal instances of C4D or Z4D where you run your own OS or hypervisor, apply your vendor's fixes when available. For hypervisors inside a VM, the same CPU information update applies, followed by a stop and start. For GKE, updated node images for Turin-based bare metal instances will be made available, and upgrading nodes picks up the CPU information update, though as of today the bulletin does not yet list them as available.

How the AMD Turin CPU flaws work, and why they matter

The AMD Turin CPU flaws belong to a family of problems called transient execution vulnerabilities. Modern processors speculate: they execute instructions ahead of time, before knowing whether those instructions should run at all, and then unwind the results if the guess was wrong. The architectural state, the data your programs actually see, is corrected. But traces of the speculative work remain in the processor's internal structures, such as caches and scheduling buffers, and those traces can be measured with careful timing.

Transient Scheduler Attacks exploit that gap through the processor's scheduler. An attacker who can run code on the same processor core arranges for the CPU to speculatively schedule work in a way that depends on secret data belonging to someone else, such as another process or the kernel. The attacker cannot read the secret directly. Instead, the attacker measures timing side effects of the speculation and infers the data from them, one observation at a time.

The three flaws differ in where the leaked data comes from. TSA-SQ (CVE-2024-36350) may allow an attacker to infer data from previous stores, potentially resulting in kernel-to-user data leakage, per AMD's assessment. TSA-L1 (CVE-2024-36357) may allow an attacker to infer data from the L1 data cache, potentially resulting in leakage across privileged boundaries such as host-to-guest, guest-to-guest, kernel-to-user, and user-to-user contexts. The new CVE-2026-0004, called TSA-Fill by the Xen Project, may allow an attacker who can run code on the system to infer data in the L1D cache, again potentially across privileged boundaries.

For a business reader, the practical translation is this: the boundary that matters is not the network, it is the processor core. If an attacker can execute code on your system, for example through a compromised container, a malicious tenant, or an exploited application, these flaws offer a way to pull data out of memory regions the attacker should never reach. That is why the CVSS vectors from AMD all begin with AV:L, local attack, and why AMD classifies all three as requiring high attack complexity but only low privileges.

Why this matters for virtualized and cloud environments specifically: in a multi-tenant cloud, the isolation you rely on between your workload and everyone else's is enforced partly by the hypervisor and partly by the CPU itself. Google has already mitigated the cross-VM and VM-to-host cases on its side. What remains is the case where an attacker is already inside your VM, on the same core as your other processes and your kernel. In that scenario, the guest operating system's mitigations, enabled by a patched kernel that knows about these flaws, are the control that stands between the attacker and your data. That is why Google is updating the CPU information that VMs report, so a patched guest kernel can turn on its mitigations, and why the stop-and-start is required to make the change take effect.

There is also a performance dimension. AMD's technical guidance states that both platform firmware and OS updates are needed to mitigate the flaws fully on Turin servers running on your own hardware, and that the mitigation may affect performance. Administrators should weigh the risk to their own workloads. That trade-off is familiar to anyone who managed the Spectre and Meltdown mitigations years ago, and it means the decision is not purely a patch-and-forget exercise for performance-sensitive systems.

Organizations running AMD's newer desktop and workstation silicon should note the scope of AMD's Zen 5 bulletin: it covers not only EPYC 9005 series server processors but also EPYC Embedded 2005, 4005, and 9005 series, Ryzen 9000 series desktop processors, Ryzen AI400 series desktop processors, Ryzen Threadripper PRO 9000 WX-series, and Ryzen Embedded 9000 and P100 series processors. The new CVE-2026-0004 advisory additionally lists AMD EPYC series processors and EPYC Embedded 2005 and 9005 series. For teams evaluating Turin-class hardware for on-premises AI or virtualization, the relevant pages on AMD EPYC 9005 (Turin), AMD Threadripper PRO 9000, and AMD Threadripper 9000 HEDT AI CPU cover these processor families in more depth.

What the evidence does and does not show

The sources establish what the flaws are, who reported them, and what mitigations exist. They also leave several questions open, and it is worth being precise about the limits.

No exploitation has been reported. Neither Google nor AMD reports any exploitation in its bulletins, and none of the three flaws is in CISA's KEV catalog as of today. That is a meaningful signal, but it is a point-in-time statement, not a guarantee. Side-channel attacks of this class have historically moved from academic demonstration to practical concern over time, and the absence of a KEV entry today says nothing about next quarter.

The attack prerequisites are significant but not trivial. AMD classifies all three as local attacks with high attack complexity requiring only low privileges. In plain terms, an attacker needs to already run code on the affected system, and the attack is technically demanding. But "low privileges" describes exactly the position of a compromised container, a malicious library, or an exploited web application inside a VM, which is the environment most organizations actually run.

The severity picture is mixed. Google rates the issue Medium. AMD's CVSS scores are 5.6 for the two earlier flaws and 5.7 for the new one, with high confidentiality impact and no integrity or availability impact in the vectors AMD published. AMD explicitly encourages independent CVSS calculation, since scores may change subject to implementation. A regulated organization with CUI or ePHI in a shared environment may reasonably weight the confidentiality impact differently than the base score suggests.

Key operational details are not yet published. Google's bulletin lists nothing to do in the meantime for VMs whose OS vendor has not yet shipped a fix, and it does not say how to tell when the CPU information update has reached a VM. That second gap matters practically: the stop-and-start instruction depends on the update having arrived, and Google has not provided a verification method. For GKE, updated node images for Turin-based bare metal instances are promised but not yet listed as available.

The guest OS fix rollout is uneven. A mitigating kernel commit for Zen 5, including the new variant, is in the Linux kernel source tree, but Debian has fixed CVE-2026-0004 only in its unstable branch, and its security tracker still lists the kernels in bookworm, trixie, and forky as vulnerable. Organizations on enterprise Linux distributions or other vendors should expect similar lag and should track their own vendor's advisories rather than assume availability.

AMD's correction is itself a finding. The Xen Project's note that AMD had previously said Zen 5 CPUs were not vulnerable to TSA-SQ and TSA-L1, followed by AMD's revised assessment that Zen 5 processors are impacted differently from previously characterized processors, is a reminder that initial vulnerability scoping can change. For procurement and risk teams, the lesson is to treat "not affected" statements about new silicon as provisional until independent research and vendor follow-ups converge.

What remains unknown. The sources do not quantify how much data an attacker could realistically extract, how long such an attack takes in practice, or what performance impact the mitigations impose in specific workloads. AMD says the mitigation may affect performance and that administrators should weigh the risk to their own workloads, but provides no figures in the material reviewed here. Organizations that need those answers for capacity planning will need to test their own workloads once firmware and OS updates are in hand.

Part 2 of this analysis covers what regulated businesses should do next, how the disclosure maps to incident response and risk management expectations under frameworks such as NIST SP 800-61 Rev. 3 and CISA's Cross-Sector Cybersecurity Performance Goals, and when to involve counsel or your assessment body. For teams tracking other active vulnerability disclosures in the meantime, our recent coverage of actively exploited SharePoint flaws and a Check Point flaw allowing code execution with root privileges illustrates the broader patching environment these CPU fixes land in. Questions in the meantime can go through our contact page.

Compliance and Risk Implications for Regulated Organizations

A side-channel flaw in a processor rarely triggers a compliance obligation on its own. What triggers obligations is the combination of three things this story contains: a vulnerability affecting shared infrastructure, a mitigation that requires action on your side, and data that regulations require you to protect. If you run workloads on the affected Google Cloud machine series (C4D, N4D, H4D, Z4D, and G4, including bare metal C4D and Z4D instances), all three are likely present.

For defense contractors, the analysis starts with whether controlled unclassified information touches the affected instances. NIST SP 800-171's incident response family requires an operational incident handling capability and the tracking, documenting, and reporting of incidents. A vendor bulletin about a hardware flaw in infrastructure you use is exactly the kind of event that process should capture: identified, assessed, tracked to closure, and documented. DFARS 252.204-7012 requires reporting a cyber incident affecting covered defense information to DoD within 72 hours of discovery, but neither Google nor AMD reports any exploitation in their bulletins, and none of the three flaws is in CISA's KEV catalog. Absent evidence of exploitation, this is a vulnerability management event, not a reportable incident. The distinction matters, and your documentation should show you made it deliberately.

For covered entities and business associates handling electronic protected health information, the HIPAA Security Rule requires a risk analysis under 45 CFR 164.308(a)(1)(ii)(A). A multi-tenant cloud instance where a flaw could, in principle, let code in one process infer data from another belongs in that risk analysis if ePHI runs on the affected series. AMD classifies all three flaws as local attacks with high attack complexity requiring only low privileges, and Google rates the issue Medium. That is a real but bounded risk profile, and writing it down with those citations is what an auditor will want to see.

For organizations working toward PCI DSS or SOC 2, the relevant question is evidence. PCI DSS v4.0.1 covers 12 control areas across cardholder data environments, and the AICPA SOC 2 framework's Confidentiality and Security Trust Services Criteria both expect you to know your vulnerabilities and remediate them on a defined timeline. A stop-and-start instruction from your cloud provider that sits unactioned for months is a finding waiting to happen. The remediation is cheap; the gap in your vulnerability management record is what costs you.

One more compliance note worth underlining: AMD states that both platform firmware and OS updates are required to fully mitigate the flaws on Turin servers on your own hardware, and that the mitigation may affect performance. If you decide, after weighing the risk to your workloads, to defer or skip part of the mitigation, that decision and its rationale should be documented. Regulators and assessors do not expect zero risk. They expect reasoned, recorded risk decisions.

What This Means for Regulated Industries

Defense contractors

Start with an inventory question: does any system in your CUI boundary run on the affected Google Cloud series, or on self-hosted AMD EPYC 9005 (Turin) hardware? If the answer is yes, treat the vendor guidance as a tracked action item in your POA&M with an owner and a due date. For self-hosted Turin servers, AMD's guidance requires both PI firmware from your OEM and OS updates, so the timeline is longer and depends on your server vendor's BIOS release schedule. Contact your OEM now rather than waiting. The CMMC assessment environment is unforgiving about vulnerabilities that were known, documented, and left open without a written rationale. If you are in the middle of a CMMC readiness effort, close this one before your assessor finds it.

Healthcare

Hospitals and health systems increasingly run analytics, imaging pipelines, and AI workloads on cloud instances, and AMD's Zen 5 EPYC line, including Turin, is a common choice for exactly those workloads. The exposure here is cross-process inference inside a VM: an attacker who can run code on the same processor core could infer data from other processes or the kernel. If your threat model already assumes a compromised workload (and after ransomware, it should), this flaw adds a path from one compromised workload to data in neighboring processes. Given that IBM puts the average healthcare breach at $6.64M and HHS recorded 725 large healthcare breaches in 2024, layered defense is not optional. Patch the guest OS when your vendor ships the fix, stop and start the affected VMs, and record the action in your risk analysis documentation.

Legal

Law firms hold client confidences that carry privilege obligations independent of any specific regulation. The realistic scenario here is not a nation-state actor; it is a compromised container or a malicious tenant in a shared environment inferring data from a neighboring process. Firms running e-discovery platforms, document review, or client portals on the affected Google Cloud series should confirm with their cloud and platform vendors that guest OS fixes are applied and the stop-and-start has been performed. If you cannot confirm it, ask. Client trust letters and cyber insurance applications increasingly ask about cloud vulnerability management, and "we did not know our provider issued a bulletin" is a weak answer.

Financial services

Banks, fintechs, and payment processors face a familiar pattern: a medium-rated, high-complexity vulnerability that is individually unremarkable but sits inside an environment where examiners expect demonstrable third-party risk management. Your cloud provider has applied mitigations against attacks between VMs and between VMs and the host; the residual risk is inside a single VM, between processes. That means the fix is on your side of the shared responsibility line, which is precisely where examiners look hardest. Fold the vendor bulletin into your vendor management file, track the guest OS patch and the stop-and-start to completion, and note that the mitigation may affect performance so capacity planning is informed, not surprised.

Your Action Plan for This Month

  1. Inventory your exposure. Identify every workload you run on Google Cloud C4D, N4D, H4D, Z4D, or G4 instances, including bare metal C4D and Z4D, and every self-hosted server on AMD EPYC 9005 (Turin) or other Zen 5 silicon. You cannot patch what you have not mapped.
  2. Read the primary sources. Review Google's security bulletin, AMD's Zen 5 bulletin, and the CVE-2026-0004 advisory directly rather than relying on summaries. The guidance differs by service type.
  3. Subscribe to your OS vendor's advisory feed. Google's bulletin says to install your OS vendor's fix when it ships. Know the moment it does. Note that as of today, Debian has fixed CVE-2026-0004 only in its unstable branch, with bookworm, trixie, and forky kernels still listed as vulnerable, so your distribution's status matters.
  4. Plan the stop-and-start, not just a reboot. Google is explicit: "Rebooting the guest OS isn't enough." After the CPU information update reaches a VM and your patched kernel enables mitigations, stop and start the VM. Schedule the maintenance window now.
  5. Handle bare metal separately. If you run your own OS or hypervisor on a C4D or Z4D bare metal instance, apply your vendor's fixes when available. For self-hosted Turin servers, remember AMD requires both platform firmware and OS updates to fully mitigate, so open a ticket with your OEM for the BIOS update.
  6. Check GKE node images. Updated node images for Turin-based bare metal instances were not yet listed as available at publication. Assign someone to monitor and upgrade nodes when they ship.
  7. Verify Xen and hypervisor coverage. The Xen Project has published hypervisor patches and notes that microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23. If you run nested hypervisors inside VMs, the same CPU information update and stop-and-start apply.
  8. Test for performance impact before production. AMD's guidance warns the mitigation may affect performance. Benchmark representative workloads with mitigations enabled so the capacity conversation happens before the maintenance window, not after.
  9. Document the risk decision. Record the vulnerability, the CVSS ratings AMD published (5.6 for the two TSA flaws under CVSS 3.1, 5.7 for CVE-2026-0004 under CVSS 4.0), the actions taken, and any deferral with its rationale. This is the evidence SOC 2, PCI DSS, and NIST SP 800-171 assessors ask for.
  10. Confirm no exploitation indicators. None of the three flaws is in CISA's KEV catalog and neither vendor reports exploitation. Still, have your monitoring team confirm no anomalous behavior on affected hosts, and preserve that check in your records.

How Petronella Technology Group, Inc. Helps

Petronella Technology Group, Inc. works with regulated businesses and defense contractors that cannot treat cloud and hardware vulnerabilities as someone else's problem. Our cybersecurity services include vulnerability management and patch coordination across cloud and on-premises environments, and our managed detection and response service provides 24/7 threat monitoring, AI-powered analytics, and human-led investigation, with cloud coverage that integrates Microsoft 365, Azure, AWS, and Google Workspace to detect unauthorized access and suspicious activity. MDR reporting is designed to provide the evidence auditors need for HIPAA, CMMC, PCI DSS, SOC 2, and NIST 800-171 verification.

On the compliance side, our compliance practice helps organizations map events like this into their risk analysis, POA&M, and incident response documentation, with every practitioner on the team holding the CMMC-RP designation. For defense industrial base and healthcare clients that cannot send controlled data to a public-cloud SOC, our private AI cluster and AI-plus-human hybrid analysis stack keep monitoring in an environment built for that constraint. Where hardware choices are on the table, we advise on platforms including AMD EPYC 9005 (Turin) and related AMD Threadripper PRO 9000 systems, including the mitigation and performance tradeoffs AMD describes.

If you need a second pair of eyes on your exposure to the AMD Turin CPU flaws, or help turning vendor bulletins into documented, audit-ready action, contact us for a free 30-minute scoping consultation.

Sources

Frequently Asked Questions

Are the AMD Turin CPU flaws being exploited in the wild?

No exploitation has been reported. As of publication, none of the three flaws appears in CISA's KEV catalog of exploited vulnerabilities, and neither Google nor AMD reports any exploitation in its bulletins. AMD classifies all three as local attacks with high attack complexity requiring only low privileges.

Do I need to reboot or stop and start my VM to fix this?

You need to stop and start the VM, not merely reboot it. Google's bulletin states that after the CPU information update reaches a VM and a patched guest kernel enables its mitigations, the VM must be stopped and started. As Google puts it: "Rebooting the guest OS isn't enough."

Which Google Cloud machine types are affected by the AMD Turin CPU flaws?

The affected series are C4D, N4D, H4D, Z4D, and G4, including bare metal instances of C4D and Z4D. Turin is the code name for fifth-generation AMD EPYC processors. Google has already applied mitigations against attacks between VMs and between VMs and the host; the residual risk is between processes inside a single VM.

What are the CVE numbers for the three AMD Turin flaws?

Two of the flaws, TSA-SQ (CVE-2024-36350) and TSA-L1 (CVE-2024-36357), were first disclosed on July 8, 2025 for earlier EPYC processors. The third, CVE-2026-0004, is new and may let an attacker who can run code on a system infer data in the processor's L1 data cache. The Xen Project calls the new flaw TSA-Fill.

Does this affect self-hosted AMD EPYC 9005 servers, not just Google Cloud?

Yes. AMD's Zen 5 bulletin covers EPYC 9005 series and other Zen 5 products, and states that both platform initialization firmware and operating system updates are required to fully mitigate the applicable TSA vulnerabilities. Contact your OEM for the BIOS update specific to your product, and note that the mitigation may affect performance.

Is this a compliance problem for my CMMC or HIPAA program?

It is a vulnerability management event that belongs in your documentation, not a reportable incident on the current evidence. NIST SP 800-171's incident response family requires tracking, documenting, and reporting of incidents, and the HIPAA Security Rule requires a risk analysis. Record the bulletin, the actions you took, and the rationale for any deferral. Neither vendor reports exploitation, and the flaws are not in CISA's KEV catalog.

If you want help working through this against your own environment, call Penny, our AI assistant, at 919-348-4912 to book a consultation, or reach Petronella Technology Group, Inc. through our contact form.

Get the 2026 Cybersecurity Survival Guide

Free, practical, and specific to regulated environments. We will email it to you.

No spam. Unsubscribe anytime.

Talk to Petronella Technology Group, Inc.
Private, on-premises AI and compliance for regulated data. Call 919-348-4912, get a free AI assessment, or explore our AI, cybersecurity, and compliance services.