SecPod

Learn Search

Search across all Learn content

← Back to Expressions & POVs
ZombieLoad is back!

ZombieLoad is back!

Nov 14, 2019By Vidita V Koushik3 min read

Does the name ZombieLoad ring a bell with you? A new variant of the infamous ZombieLoad attack is around. ZombieLoad v2 enables attack on Intel CPUs designed to be resistant against the previously MDS attacks. Zombieload v2 even affects processors in the latest Intel Cascade Lake CPU family. Vulnerability management solution is highly required here.

This new vulnerability called ZombieLoad is similar to Microarchitectural Data Sampling (MDS) and is called Transactional Synchronization Extensions (TSX) Asynchronous Abort (TAA). Microarchitectural Data Sampling (MDS) is a set of speculative execution side-channel vulnerabilities (detailed in our blog)  in May 2019. Auto patching can help patch this vulnerability. ZombieLoad v2 not only uses speculative execution but also utilizes the same buffers (store buffer, fill buffer, load port writeback data bus) as MDS to leak sensitive information. Tracked as CVE-2019-11135, the vulnerability affects Intel® Transactional Synchronization Extensions (Intel® TSX). Intel TSX is an extension to the x86 instruction set architecture that adds hardware transactional memory support. TSX helps to improve the performance of multi-threaded software.

Intel TSX supports atomic transactions which either committs or aborts. An abort causes the memory writes during the transaction in Intel TSX to roll back to the state before the start. Intel TSX also supports two kinds of aborts: Synchronous and Asynchronous. An asynchronous abort occurs due to microarchitectural reasons or under such conditions when a different logical processor tries to write to a cache line in the transaction’s read set or when the memory buffer exceeds. The abort is unrecoverable and generally results in the termination of the process that caused it.

As explained by Intel, when an abort initiated, there are certain loads in the transaction that are yet complete. These loads read data from microarchitectural structures and speculatively pass it on to dependent operations. The data stored in microarchitectural structures can later retrieved. Thus, the exploitation of this bug requires a local attacker who monitors the execution time of TSX regions to infer the memory state by comparing abort execution times.

Affected Products

Affects all Intel CPUs that support TSX. List of specific Intel processors affected found here.

Impact

Successful exploitation of this vulnerability allows a local attacker to steal sensitive data such as encryption keys, passwords, etc. from the operating system kernel or other processes. An attacker who has local access to a virtual environment could infer data protected by architectural mechanisms from another virtual machine or the hypervisor itself.

Solution/Workaround

Intel has released security patches with microcode updates to handle the TAA vulnerabilities.
Microsoft has also released updates to mitigate this vulnerability. Microsoft states that the OS protections are enabled by default on Windows Server OS and Windows Client OS Editions. Red Hat has released a script used to detect if their Intel system affected by this vulnerability. VMware has released  Hypervisor-Specific Mitigations for VMware ESXi, Workstation, and Fusion. Ubuntu also released updates to keep its customers protected.

Workaround

Microsoft and Linux have also released advisories to disable TSX as a workaround.

Please refer to this KB Article to apply the patches using SanerNow.

Featured Posts

Open What Is a Kubernetes Network Policy?
What Is a Kubernetes Network Policy?

Point of View

What Is a Kubernetes Network Policy?

A Kubernetes network policy controls incoming and outgoing connections between Pods and other network destinations. The article explains how ingress and egress rules work, why default network access can create security risks, and how to configure and verify traffic restrictions. It also covers common policy mistakes and how Saner COSP's COAE and COPM modules support Kubernetes exposure visibility and configuration assessment.

Oct 16, 2026

Open Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters
Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters

Point of View

Hybrid Cloud Security for Kubernetes Across Standalone, On-Prem, and Managed Clusters

Hybrid cloud security for Kubernetes involves managing security risks across standalone, on-premises, and managed clusters. The blog explains the differences between Amazon EKS, Microsoft AKS, and Google GKE, common security challenges, and practical steps for maintaining consistent security controls. It also covers how Saner COSP helps teams assess configurations, manage access, prioritize risks, and track remediation across Kubernetes environments.

Oct 16, 2026

Open Excellence Is a Choice
Excellence Is a Choice

Point of View

Excellence Is a Choice

Oct 14, 2026

Open AWS Security Best Practices for Financial Services: Beyond Configuration Management
AWS_Security_Best_Practices_For_Financial_Services

Point of View

AWS Security Best Practices for Financial Services: Beyond Configuration Management

Oct 13, 2026