The newly disclosed StackWarp vulnerability (CVE-2025-29943) exposes a critical weakness in AMD’s confidential computing stack, affecting a wide range of Zen 1 through Zen 5 processors. Researchers from the Helmholtz Center for Information Security (CISPA) have shown that a privileged attacker on the host can subvert AMD SEV-SNP, compromising the integrity of code execution inside confidential virtual machines (Confidential VMs) that were assumed to be isolated from an untrusted hypervisor.
What is StackWarp and how it impacts AMD SEV-SNP confidential computing
AMD SEV-SNP (Secure Encrypted Virtualization – Secure Nested Paging) is designed to protect virtual machines in hostile or multi-tenant environments. Guest memory is encrypted, and the threat model explicitly assumes that the host OS and hypervisor are not trusted. This makes SEV-SNP a foundation for many confidential computing offerings in public clouds and enterprise data centers.
StackWarp undermines this model. Despite SEV-SNP being enabled, CISPA’s work demonstrates that a sufficiently privileged attacker on the host can manipulate low-level CPU state to interfere with execution inside a protected VM. In practice, this means the host can regain control over what was supposed to be a strongly isolated guest environment.
AMD characterizes the underlying issue as an “improper access control” to a specific processor pipeline configuration. Exploiting this flaw allows an attacker to corrupt or modify the stack pointer of code running inside a confidential VM, opening the door to precise and powerful attacks on the guest’s control flow.
Technical overview of the StackWarp (CVE-2025-29943) attack
According to the CISPA team, StackWarp centers on manipulating an undocumented bit in a model-specific register (MSR). MSRs are special-purpose CPU registers used to control processor features and performance characteristics and are typically accessible only to privileged code such as the hypervisor or kernel.
When SMT/Hyper-Threading is enabled, two logical cores share the same physical core. StackWarp abuses this by running attacker-controlled code on one sibling logical core, which toggles the hidden MSR bit. This, in turn, influences how the CPU manages the stack pointer inside the protected VM running on the other logical core.
By carefully timing and crafting these manipulations, an attacker can:
- perform control-flow hijacking, redirecting program execution inside the guest VM;
- alter critical data on the stack, such as return addresses or saved registers;
- achieve remote code execution and privilege escalation within the confidential VM;
- extract sensitive secrets and cryptographic keys from protected memory.
In proof-of-concept demonstrations, the researchers were able to recover an RSA‑2048 private key from a single faulty digital signature, bypass OpenSSH authentication and the sudo password prompt, and ultimately execute code in kernel mode inside the VM. Kernel-level compromise effectively gives full control over the guest operating system despite SEV-SNP protections.
Affected AMD processors and real-world risk assessment
StackWarp affects AMD processors based on Zen 1, Zen 2, Zen 3, Zen 4, and Zen 5 microarchitectures. This includes the AMD EPYC server families widely used in cloud service provider platforms and large-scale virtualized infrastructures. The complete list of affected SKUs is maintained in AMD Security Bulletins.
Exploitation, however, is not trivial. Successful use of CVE-2025-29943 requires privileged access on the host system where confidential VMs run. In realistic scenarios, this corresponds to:
- a compromised cloud or virtualization host, for example via a separate vulnerability or misconfiguration;
- a malicious or coerced administrator with high-level access;
- an insider with control over the hypervisor or management infrastructure.
The CISPA researchers conclude that under these conditions “the integrity of execution inside confidential virtual machines and the isolation between host and guest can no longer be assumed to be guaranteed.” For multi-tenant cloud environments built on SEV-SNP, this significantly weakens the trust model that many customers rely on.
Why cloud and enterprise environments should care
For organizations using confidential VMs on AMD EPYC, the consequences of StackWarp can be far-reaching:
- theft of confidential material such as TLS, SSH, and VPN keys, passwords, and access tokens from guest memory;
- impersonation of legitimate services and users by abusing stolen credentials and keys;
- long-term, stealthy persistence inside high-value workloads, even with SEV-SNP enabled;
- reduced confidence in multi-tenant cloud security where multiple customers share the same physical hardware.
StackWarp reinforces a broader lesson from past hardware attacks (such as speculative execution flaws): even advanced hardware isolation mechanisms are not absolute. They must be combined with strong operational security and continuous monitoring.
AMD response, microcode updates, and mitigation strategies
AMD has assigned CVE-2025-29943 a low severity rating, primarily because exploitation requires privileged host access. Nonetheless, the company has released microcode updates for AMD EPYC server processors, which it states have been available since July 2025.
Additional AGESA firmware updates for EPYC Embedded 8004 and 9004 platforms are planned for April 2026. Administrators should track AMD’s security advisories and ensure that system firmware, BIOS/UEFI, and hypervisors are updated as vendors roll out patches that incorporate the new microcode.
To reduce exposure to StackWarp and similar hardware attacks, organizations relying on AMD SEV-SNP confidential VMs should:
- Prioritize microcode and firmware updates that address CVE-2025-29943 across all affected hosts as soon as they become available.
- Revisit the threat model for confidential computing, recognizing that SEV-SNP does not automatically make the host or hypervisor sufficiently trustworthy.
- Tighten access control and monitor privileged accounts, including administrators and service identities, and minimize the number of users with host-level rights.
- Deploy strong key management (e.g., HSMs, dedicated KMS, frequent key rotation) so that a single compromise of a confidential VM has limited blast radius.
- Evaluate disabling SMT/Hyper-Threading on the most sensitive hosts, where performance requirements allow, to remove the sibling-core attack vector.
StackWarp demonstrates that even flagship confidential computing technologies like AMD SEV-SNP can harbor subtle hardware weaknesses. Organizations building security strategies around confidential VMs should treat them as one layer in a broader defense-in-depth architecture, not as a stand-alone guarantee of isolation. Regular firmware patching, rigorous access governance, penetration testing, and close attention to emerging hardware security research remain essential to protecting critical workloads and data.
