In 2024, Microsoft’s own security researchers documented ransomware operators actively exploiting a hypervisor vulnerability, CVE-2024-37085, to gain full administrative control over ESXi hosts and mass-encrypt every virtual machine running on them. Critically, the businesses affected had no way to patch this themselves. That is because the vulnerability lived in infrastructure they did not control.
This guide addresses that specific fear: an attack exploits a layer of infrastructure sitting beneath you, one you never configured and cannot fix, and it has nothing to do with your own security practices. This guide explains exactly how that exposure works, and what removes it entirely rather than mitigating it.
📖 How do dedicated servers improve data security overall?
Read How Dedicated Servers Improve Data Security for Online Businesses, a complete guide to the security advantages of physical isolation, full configuration control, encryption, and compliance support on dedicated infrastructure.
The Security Problem With Shared Hardware
Understanding why isolation matters starts with understanding precisely what a virtualised or shared hosting environment shares, and what that sharing enables.
When multiple tenants share a physical server, they share the following hardware components:
CPU and CPU cache – All processes on the same physical machine share the processor’s L1, L2, and L3 caches. These caches store recently accessed data to improve performance. Critically, they store this data regardless of which process accessed it or which tenant it belongs to.
Memory bus – The pathway between the CPU and RAM is shared across all processes on the physical machine. High-memory-bandwidth operations by one tenant affect memory access latency for all others.
Network interface – The physical network interface card handles all traffic for all VMs on the host. While virtual switches provide logical isolation, the physical NIC and its buffers are shared.
Storage controllers – Disk I/O from all tenants passes through the same physical storage controller, creating I/O contention and, in some configurations, timing side channels.
Each of these shared components is a potential attack surface. Software controls can limit what data flows between them, but they cannot eliminate the fact that the components themselves are shared.
Side-Channel Attacks – The Threat That Software Cannot Block
Side-channel attacks are the most technically significant security risk of shared hardware, and the one that most clearly demonstrates why software isolation has limits.
Spectre and Meltdown
In January 2018, security researchers disclosed two hardware vulnerabilities affecting virtually every modern processor manufactured since the 1990s: Spectre and Meltdown. Both exploit the CPU’s speculative execution feature, an optimisation that predicts which instructions will be needed next and executes them in advance to reduce latency.
Meltdown allows a malicious process to read kernel memory that should be inaccessible. In practice, in a virtualised environment, this means a process in one VM can, under certain conditions, read memory belonging to the hypervisor or other VMs on the same physical host.
Spectre is broader and more difficult to patch. It exploits the branch prediction component of speculative execution to cause processes to reveal their memory contents through the shared CPU cache. Unlike Meltdown, Spectre works across process boundaries even with software isolation in place, because it exploits the timing of cache access rather than direct memory access.
Software updates patched both vulnerabilities, but the patches introduced performance overhead, in some cases 10-30% on I/O-intensive workloads. Furthermore, researchers continue to discover variants of these attacks, because the underlying mechanism, shared CPU cache with speculative execution, is fundamental to how modern CPUs achieve performance.
On a dedicated server, these attacks are irrelevant. That is because there are no co-located processes to attack from, and no co-located attackers to attack you. As a result, the shared CPU cache contains only your processes.
Cache Timing Attacks
Beyond Spectre and Meltdown, a broader class of cache timing attacks exploit the shared CPU cache to extract information about other processes. The fundamental mechanism is straightforward: by measuring how long it takes to access specific memory locations, an attacker can determine whether those locations are in the cache, which reveals information about what other processes have recently accessed.
Applied to cryptography, cache timing attacks have been demonstrated to extract private keys from co-located processes by measuring the cache access patterns of encryption operations. While these attacks require significant technical sophistication, they represent a real threat for environments handling high-value cryptographic material, private keys, payment credentials, authentication tokens.
Physical isolation eliminates this attack class because the attacker and target do not share a CPU cache.
📖 Bare metal vs virtualised servers, the security comparison
Read Physical Server vs Virtual Server: What’s the Real Difference?, a complete comparison of physical and logical isolation models, including the security implications of each architecture.
Hypervisor Vulnerabilities – When the Isolation Layer Fails
VPS and cloud environments rely on a hypervisor to provide logical isolation between tenants. The hypervisor is the software layer that divides the physical machine into multiple virtual machines and enforces the boundaries between them.
The security of a VPS environment is only as strong as the hypervisor. When a hypervisor vulnerability is discovered, that isolation fails, potentially allowing one VM to access another’s memory, network traffic, or storage.
Hypervisor vulnerabilities, not a hypothetical risk
| Year | Vulnerability | Impact |
|---|---|---|
| 2009 | Cloudburst (VMware) | Guest-to-host code execution |
| 2015 | VENOM (QEMU/KVM/Xen) | VM escape via virtual floppy controller |
| 2024 | CVE-2024-37085 (ESXi) | Ransomware mass-encryption at scale |
Table listing three real hypervisor vulnerabilities across 15 years: Cloudburst in 2009 affecting VMware, VENOM in 2015 affecting QEMU/KVM/Xen, and CVE-2024-37085 in 2024 affecting ESXi and exploited for ransomware mass-encryption.
Three Real Vulnerabilities, Three Different Vendors
Hypervisor vulnerabilities are rare but recurring. A selection of significant examples:
VENOM (2015) – A buffer overflow in the virtual floppy disk controller in QEMU (used by KVM and Xen) allowed an attacker with access to a guest VM to escape the VM and execute code on the host. All VMs on the same host were potentially exposed.
Cloudburst (2009) – A VMware Workstation vulnerability allowed code execution on the host from within a guest VM, demonstrating VM escape on a widely deployed hypervisor.
CVE-2024-37085 (2024) – According to <a href=”https://www.microsoft.com/en-us/security/blog/2024/07/29/ransomware-operators-exploit-esxi-hypervisor-vulnerability-for-mass-encryption/” rel=”noopener”>Microsoft’s own security research</a>, ransomware operators exploited a misconfiguration in how domain-joined ESXi hypervisors grant administrative access, obtaining full control and encrypting every hosted VM simultaneously. This is not a theoretical hypervisor vulnerability, it was actively used to compromise production infrastructure at scale.
What This Means for Patching
Each of these vulnerabilities, at the moment of disclosure, represented a period of exposure for all tenants co-located on affected infrastructure. Patching requires hypervisor updates that typically require brief downtime for the host, affecting all VMs simultaneously, and that patch timeline is entirely outside your control.
On a dedicated server, there is no hypervisor. There is no software isolation layer that can fail. The only isolation is physical, hardware that belongs entirely to you.
📖 The complete security hardening checklist for dedicated servers
Read Dedicated Server Security Checklist: How to Harden Your Server After Setup, a phase-by-phase guide covering every security control that physical isolation makes possible, from SSH hardening to WAF installation.
Lateral Movement – Containment as a Security Property
In security, lateral movement refers to an attacker’s ability to move from one compromised system to other systems in the same environment. Containing lateral movement, limiting how far a successful breach can spread, is a fundamental principle of security architecture.
In shared virtualised environments, lateral movement has additional pathways that do not exist in physically isolated infrastructure.
VM-to-VM Lateral Movement
After a hypervisor vulnerability allows an attacker to escape a compromised VM, they have access to the hypervisor, from which all other VMs on the same host are reachable. This effectively turns a breach of one tenant’s environment into access to all tenants on the same physical host, exactly the pattern Microsoft documented in the CVE-2024-37085 ransomware campaign.
Furthermore, even without a hypervisor escape, VMs on the same host share network infrastructure at the physical layer. While virtual switches enforce logical separation, misconfigurations, VLAN hopping attacks, and ARP spoofing in the virtual network layer create lateral movement opportunities that physical network separation eliminates.
Supply Chain and Shared Component Vulnerabilities
In shared environments, multiple tenants share the same base images, the same hypervisor version, the same network infrastructure, and the same management plane. A vulnerability in any shared component affects all tenants simultaneously.
On dedicated infrastructure, your server has no shared components with any other customer. A vulnerability affecting another customer’s environment does not affect yours because there are no shared components through which it can propagate.
IP Reputation and Shared Network Identity
On shared hosting environments, multiple customers share the same IP address or the same IP subnet. This creates a security dependency that is entirely outside your control.
If another customer on the same shared hosting environment sends spam, their activity, and consequently your shared IP’s reputation, is affected. Email deliverability suffers for all customers sharing the IP. Some security tools and email servers block entire IP ranges associated with known spam or malicious activity.
Furthermore, if another customer’s compromised site hosts malware, phishing pages, or command-and-control infrastructure, threat intelligence feeds may list the IP address of the entire shared hosting environment, affecting all customers sharing that IP.
A dedicated server has a dedicated IP address. Your IP’s reputation is determined entirely by your own activity. No other customer’s security posture affects your network identity.
📖 How does DDoS protection work on dedicated infrastructure?
Read What Is DDoS and How Does It Affect Your Website?, a complete guide to DDoS attack types and how network-level and application-level mitigation work on dedicated infrastructure.
Resource Exhaustion as a Denial-of-Service Vector
In shared environments, resource exhaustion by one tenant can affect the availability of all tenants on the same host. Discussions of this typically focus on the noisy neighbour problem for performance, but it has direct security implications for availability.
A malicious tenant on the same shared host can intentionally consume CPU, RAM, network bandwidth, or disk I/O to degrade or deny service to other tenants. This is a denial-of-service attack that does not require any network-facing exploitation, it operates entirely through shared hardware resource consumption.
Furthermore, a compromised tenant whose server has been enrolled in a botnet may generate outbound traffic or perform compute-intensive operations (such as cryptocurrency mining) that consume resources affecting all co-located tenants.
On a dedicated server, no other tenant shares your hardware. Resource exhaustion by any external party does not affect your availability unless it comes through the network, at which point it is a conventional DDoS attack that your provider’s network-level mitigation addresses.
Compliance – Physical Isolation as a Documented Requirement
Several compliance frameworks treat physical isolation as either a requirement or a significant simplification factor. Understanding why helps explain why regulators and auditors favour dedicated infrastructure.
PCI-DSS – The Payment Card Industry Data Security Standard requires businesses to isolate the Cardholder Data Environment from other systems. Physical isolation on dedicated hardware provides the clearest implementation of this requirement. Shared virtualised environments require additional documentation to demonstrate that the logical isolation between the CDE and other tenants is sufficient.
GDPR – Article 32 of GDPR requires that appropriate technical and organisational measures protect personal data. Physical isolation is one of the strongest technical measures available, it eliminates the cross-tenant attack surfaces that exist in shared environments entirely rather than mitigating them.
HIPAA – The Health Insurance Portability and Accountability Act’s Security Rule requires safeguards protecting electronic Protected Health Information. Physical infrastructure isolation directly supports the access control, audit control, and integrity requirements of the Security Rule.
ISO 27001 – The international standard for information security management requires risk assessment and the implementation of controls appropriate to identified risks. Physical isolation eliminates entire categories of identified risk, side-channel attacks, hypervisor vulnerabilities, lateral movement via shared components, rather than adding controls to manage them.
📖 How does dedicated infrastructure support PCI-DSS compliance?
Read PCI DSS Compliant Hosting: What It Actually Requires, a complete guide to how physical isolation, network segmentation, and full configuration control support the most infrastructure-intensive PCI-DSS requirements.
What Physical Isolation Does Not Address
Physical isolation is not a complete security solution. It is one layer of a defence-in-depth strategy. Understanding what it does and does not protect against prevents overconfidence.
Physical isolation does not prevent network-based attacks. Your dedicated server is still reachable from the internet. SQL injection, credential brute-forcing, and application-layer attacks all arrive through the network and are unaffected by infrastructure isolation. These require application-level controls: input validation, rate limiting, WAF rules, and strong authentication.
Physical isolation does not prevent insider threats. An administrator with legitimate access to the server can exfiltrate data regardless of physical isolation. Access controls, multi-factor authentication, audit logging, and separation of duties address this risk.
Physical isolation does not prevent supply chain attacks. If your application depends on third-party libraries, those dependencies are a potential attack vector regardless of your infrastructure model.
Physical isolation does not replace patching. The OS, web server, database, and application code still require regular security updates. Unpatched software vulnerabilities are the most common cause of successful attacks on dedicated servers.
Physical isolation is a foundational security property that eliminates specific attack categories, including every hypervisor vulnerability by definition, since there is no hypervisor to be vulnerable. The remaining attack surface is addressed by the security controls you implement on top of the isolated infrastructure.
📖 What security controls should you implement on a dedicated server?
Read Dedicated Server Security Checklist: How to Harden Your Server After Setup, a comprehensive phase-by-phase guide to the security controls that complement physical isolation and protect against the attack vectors it does not address.
Build on Infrastructure That Eliminates Risk at the Foundation
Swify’s dedicated servers give your business physical isolation, full hardware control, European datacenters, and network-level DDoS protection, the security foundation that shared environments cannot provide.
→ Explore Swify Dedicated Server PlansFrequently Asked Questions
What is a hypervisor vulnerability?
A hypervisor vulnerability is a security flaw in the software layer that manages virtual machines on shared physical hardware. When exploited, it can allow an attacker to escape a single virtual machine and access the underlying host, or other virtual machines sharing the same physical server. Microsoft documented a real example in 2024, CVE-2024-37085, exploited by ransomware operators to gain full administrative control over ESXi hosts and mass-encrypt every hosted VM.
Read Physical Server vs Virtual Server: What’s the Real Difference? for a full comparison of the security models.
What is a side-channel attack and does physical isolation prevent it?
A side-channel attack extracts information from a system by observing indirect signals: timing, power consumption, electromagnetic emissions, or cache access patterns, rather than directly accessing protected data. Cache timing attacks and Spectre are the most significant side-channel attacks for server infrastructure. Physical isolation prevents these attacks because the attacker and target no longer share a CPU cache, the shared hardware through which the attack operates does not exist when hardware is dedicated to a single tenant.
Does physical isolation protect against DDoS attacks?
Physical isolation prevents a specific DDoS-adjacent risk: resource exhaustion by other tenants. On shared hosting, a compromised co-located site generating malicious traffic can consume bandwidth and compute resources affecting all tenants. On a dedicated server, this cannot happen because there are no co-located tenants. For conventional DDoS attacks originating from the internet, dedicated server providers at enterprise datacenters provide network-level mitigation that scrubs volumetric attack traffic before it reaches your server.
Read What Is DDoS and How Does It Affect Your Website? for a complete guide to DDoS protection.
Why does shared hosting affect my IP reputation?
On shared hosting, multiple customers share the same IP address. If another customer sends spam, engages in malicious activity, or has their site compromised, that IP address may be added to email blocklists or threat intelligence feeds. All customers sharing the IP are affected, regardless of their own behaviour. A dedicated server has a dedicated IP address, and your IP’s reputation depends only on your own activity.
Read Dedicated Server vs Shared Hosting: The Real Performance Gap for a full comparison of shared vs dedicated infrastructure.
Is physical isolation required for GDPR compliance?
GDPR does not explicitly mandate physical isolation, but it requires appropriate technical and organisational measures to protect personal data. Physical isolation is one of the strongest available technical measures, it eliminates cross-tenant attack surfaces entirely rather than mitigating them with controls. For businesses handling significant volumes of personal data, physical isolation on a European datacenter dedicated server provides unambiguous data residency and a stronger compliance posture than shared environments.
Read Dedicated Servers and GDPR: What You Need to Know for a full breakdown of GDPR infrastructure requirements.
Does a dedicated server prevent all cyberattacks?
No, physical isolation eliminates specific attack categories, including every hypervisor vulnerability by definition, but does not protect against all threats. Network-based attacks, insider threats, and supply chain attacks through third-party dependencies all require their own dedicated controls regardless of infrastructure model. Physical isolation is a foundational security property; the remaining attack surface requires application-level security controls implemented on top of it.
Read Dedicated Server Security Checklist: How to Harden Your Server After Setup for the complete guide to controls that complement physical isolation.