CacheWarp is a new software fault attack on AMD SEV-ES and SEV-SNP. It allows attackers to hijack control flow, break into encrypted VMs, and perform privilege escalation inside the VM.



Securing Virtual Machines.


AMD Secure Encrypted Virtualization (SEV) is a CPU extension enabling a more secure separation between virtual machines (VMs) and the underlying hypervisor. AMD SEV allows developers to deploy VMs in an untrusted hypervisor environment securely. In other words, this means that computations in the cloud can be performed on confidential data even if the cloud provider is untrusted or compromised.

AMD SEV achieves this level of protection by encrypting the VM’s data. The encryption applies to the VM’s memory as well as its register state upon context switches. The latest and most secure variant of SEV, namely, AMD SEV-SNP, additionally prevents cloud providers from altering the data stored inside the VM.

Jump back


Traveling Through Time and Memory.

CacheWarp is a software-based fault injection attack on SEV VMs. It allows the hypervisor to revert data modifications of the VM on a single-store granularity, leading to an old (stale) view of memory for the VM.

But why is that bad? For a simple example, assume you have a variable determining whether a user is successfully authenticated. By exploiting CacheWarp, an attacker can revert the variable to a previous state and thus take over an old (already authenticated) session. Furthermore, an attacker can revert the return addresses stored on the stack and, by that, change the control flow of a victim program.

Security Breach

Practical Impact.

Security Implications.

CacheWarp enables attackers to attack AMD SEV VMs. As shown in the above videos, attackers can exploit CacheWarp to, for example, gain remote code execution and privilege escalation in the targeted virtual machine.

Fortunately, AMD has tracked the issue as CVE-2023-20592 and provides a microcode update fixing the vulnerability. For more detailed information, we recommend reading the official AMD Security Bulletin.


Is my computer vulnerable to this attack?

If you have an AMD CPU supporting AMD SEV, yes, your machine is affected. Nevertheless, if you do not rely on deploying secure virtual machines using AMD SEV, this vulnerability cannot be leveraged by an attacker.

For more details, please refer to the official AMD Security Bulletin.

What is AMD SEV?

AMD Secure Encrypted Virtualization (SEV) is a CPU extension enabling secure virtual machines in the presence of an untrusted or compromised hypervisor.

Does this work against all variants of AMD SEV, including SEV-SNP?

Yes, while the exploitation for AMD SEV-SNP is more challenging, CacheWarp can be exploited in all current variants of AMD SEV.

Does CacheWarp affect traditional virtual machine isolation?

No, CacheWarp only affects AMD SEV, as traditional virtual machines do not offer any protection against malicious hypervisors.

Is this a software or a hardware bug?

CacheWarp is a hardware bug in AMD CPUs. For guidance mitigating this vulnerability on affected CPUs, we refer to the official AMD Security Bulletin.

Is this a transient-execution attack?

No, CacheWarp is an architectural bug and thus does not fall into the category of transient-execution attacks like Meltdown and Spectre. It is also not a side-channel attack.

Is this exploited in the wild?

We do not know.

Is there more technical information about CacheWarp?

Yes, there is an academic paper.

What is CVE-2023-20592?

CVE-2023-20592 is the official reference to CacheWarp. CVE is the standard for information security vulnerability names maintained by MITRE.

Can I use the logo?

The logo is free to use, rights waived via CC0. Logo designed by Lea Mosbach.

Logo ↓ SVG ↓ PNG


We would like to thank AMD for working with us during the responsible disclosure. We want to thank our shepherd and the anonymous reviewers for their guidance, comments and valuable suggestions, as well as Leon Trampert, Moritz Lipp, and Xinyue Shen for helpful feedback on this work. This work was supported in part by Semiconductor Research Corporation (SRC) Hardware Security Program (HWS). This research is supported in part by the European Research Council (ERC project FSSec 101076409). Additional funding was provided by a generous gift from AWS. Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding parties.