As reported by SecurityAffairs, CISA has added multiple vulnerabilities affecting the Linux Kernel and Broadcom VMware ESXi to its Known Exploited Vulnerabilities (KEV) catalog, confirming that threat actors are actively exploiting these flaws in the wild. While KEV inclusion is always significant, the VMware ESXi additions deserve particularly close attention from security teams managing virtualized infrastructure.

Security Impact: As reported by SecurityAffairs, CISA has added multiple vulnerabilities affecting the Linux Kernel and Broadcom VMware ESXi to its Known Exploited Vulnerabilities (KEV) catalog, confirming that threat actors are actively exploiting these flaws in the wild.

Why the VMware ESXi Flaws Stand Out

Hypervisor-level vulnerabilities occupy a uniquely dangerous position in the threat landscape. Unlike application-layer bugs that compromise a single VM or service, a successful hypervisor escape can break the fundamental isolation boundary that all tenant separation depends on. When a guest VM can execute code on the ESXi host, an attacker gains visibility into every virtual machine running on that hardware — a scenario that is catastrophic for multi-tenant environments, cloud service providers, and managed hosting platforms.

Broadcom patched these ESXi vulnerabilities in July, but the gap between patch release and KEV catalog inclusion — typically driven by confirmed exploitation evidence — means adversaries have had months to develop and refine exploitation tooling. Organizations that deferred patching under the assumption that these were lower-priority hypervisor bugs now face an environment where public or semi-public exploit code may already be circulating.

The Linux Kernel Factor

The simultaneous addition of a Linux Kernel vulnerability to KEV compounds the risk. Linux kernel flaws — particularly those involving memory corruption, use-after-free conditions, or privilege escalation — are staples in attacker playbooks because they provide the foundational primitives needed for container escapes, root-level access, and lateral movement within Linux-based infrastructure. When combined with hypervisor-layer weaknesses, attackers gain a potential end-to-end chain: compromise a guest VM via the kernel flaw, then pivot to the hypervisor via the ESXi vulnerability.

Who Is Most Exposed

The Linux Kernel Factor
Multi-tenant virtualized environments: Cloud and hosting providers where multiple customers share ESXi hosts face the highest risk from hypervisor escape scenarios.
MSPs and managed infrastructure providers: A single unpatched ESXi host can expose dozens of client environments simultaneously.
Enterprise data centers with legacy ESXi: Organizations running older ESXi versions or those that deferred Broadcom's July patch cycle due to change management concerns.
Containerized workloads on VMware infrastructure: The combination of a Linux kernel guest vulnerability with a hypervisor escape creates a potential container-to-host-to-hypervisor attack path.

The KEV catalog is not a watchlist — it is a confirmed exploitation ledger. By the time a vulnerability appears here, the question is no longer if attackers are using it, but how many environments remain unpatched.

Shield53 Recommendations

Immediate Actions

  • Patch all ESXi hosts now. Apply the Broadcom July 2025 advisory patches across every ESXi host in your environment. Prioritize hosts serving multi-tenant or internet-exposed workloads first.
  • Inventory and verify kernel versions. Identify all Linux VMs and hosts running versions affected by the KEV-listed kernel vulnerability. Cross-reference against your CMDB to ensure no unmanaged or orphaned systems are missed.
  • Hunt for exploitation indicators. Review ESXi host logs for anomalous VM process execution, unexpected network connections from guest VMs to host management interfaces, and suspicious vmkernel messages. On Linux guests, check for unexpected privilege escalation events and new persistent mechanisms.
  • Review VM-to-host isolation controls. Verify that vSwitch segmentation, distributed firewall rules, and host-based firewall configurations on ESXi are properly enforced. Limit the ESXi management network exposure to only strictly necessary management subnets.
  • Apply defense-in-depth for hypervisor access. Ensure ESXi Shell and SSH are disabled by default, lock down root account access, and enforce vSphere Advanced Authentication where available.

Strategic Considerations

Organizations should treat hypervisor-layer vulnerabilities with the same urgency as domain controller or infrastructure-tier vulnerabilities. The blast radius of a successful ESXi compromise extends far beyond a single system — it can unravel an entire virtualized estate. Consider implementing a dedicated hypervisor patching SLA that is faster than your standard server patching cycle, and ensure your vulnerability management program explicitly tracks Broadcom VMware advisories separately from general software patches to avoid missed updates during vendor transitions.

For the Linux kernel vulnerability, prioritize kernel patching on any system that serves as a container host, jumphost, or multi-user shared environment. Memory corruption primitives in the kernel are frequently chained with other vulnerabilities — treating them as isolated issues underestimates the real-world risk.