The Shadowserver group recently identified over 41,500 internet-exposed VMware ESXi hypervisors vulnerable to CVE-2025-22224, a critical Time-of-Check Time-of-Use (TOCTOU) code execution attack. The attackers who gain administrative access to a compromised VM can exploit this flaw to execute arbitrary code on the hypervisor, gaining full control over all hosted VMs and networked assets.
Broadcom released emergency patches for ESXi and Workstation products to remediate the flaw. The CVSS score was set at 9.3. However, with active exploitations in the wild, security teams should deploy robust runtime threat detection to spot escape attempts before they are successful.
How Falco can detect VM and container escape activity
Falco, the cloud-native runtime security tool, excels at detecting suspicious activity by monitoring syscalls at the kernel level. While Falco does not block syscalls pre-execution, it can detect and alert on escape attempts before an attacker can fully execute their exploit.
Can Falco enforce pre-syscall guardrails using eBPF?
Falco leverages eBPF for syscall visibility, but it does not anchor itself in eBPF to block syscalls before execution. Instead, it operates in detection mode, analyzing system calls and generating real-time alerts based on security rules. This means that:
- Falco detects escape behaviors early, such as unexpected privilege escalations or host-level access from within a container/VM.
- Falco does not prevent the initial exploit attempt, but when combined with response actions (e.g., Kubernetes admission controllers, enforcement tools like KubeArmor, or SELinux policies), it can mitigate the impact.
What can Falco detect in VM/container escapes?
Falco provides robust rules to detect syscalls executed outside a container’s expected boundaries.
To better understand how Falco can detect container, process, and VM escapes, let’s look at how our default Falco rules work.
Detect release_agent file container escapes
The below rule is provided out-of-the-box with Falco. This rule detects attempts to exploit container escapes by modifying the release_agent file, which can occur if a privileged user with certain capabilities (like CAP_SYS_ADMIN and CAP_DAC_OVERRIDE) accesses and writes to the file within a container. The rule triggers when such a write operation happens, signaling a potential security breach.
- rule: Detect release_agent File Container Escapes
desc: >
Detects an attempt to exploit a container escape using release_agent file.
By running a container with certain capabilities, a privileged user can modify
release_agent file and escape from the container.
condition: >
open_write
and container
and fd.name endswith release_agent
and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE)
and thread.cap_effective contains CAP_SYS_ADMIN
output: Detect an attempt to exploit a container escape using release_agent file (file=%fd.name cap_effective=%thread.cap_effective evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
priority: CRITICAL
tags: [maturity_stable, container, process, mitre_privilege_escalation, T1611]Code language: YAML (yaml)Debugfs launched in privileged container
Another default Falco rule detects when the DebugFS file system debugger is launched inside a privileged container, which could be used for a potential container escape. Unfortunately, this scope is limited because it’s specifically targeting the debugfs process running within privileged containers, narrowing the focus to a particular tool and environment.
- rule: Debugfs Launched in Privileged Container
desc: >
Detect file system debugger debugfs launched inside a privileged container which might lead to container escape.
This rule has a more narrow scope.
condition: >
spawned_process
and container
and container.privileged=true
and proc.name=debugfs
output: Debugfs launched started in a privileged container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
priority: WARNING
tags: [maturity_stable, container, cis, process, mitre_privilege_escalation, T1611]Code language: YAML (yaml)Detecting access to host namespaces
In the context of CVE-2025-22224, the below custom Falco rule detects potential container escape attempts by monitoring for processes within a container that try to interact with or access the host’s namespaces. Specifically, it triggers an alert when a process executes setns or unshare system calls, which are commonly used to manipulate namespaces and potentially break out of the container, compromising the host system.
- rule: Container Escape Attempt via Namespace Access
desc: Detects attempts to access host namespaces from a container
condition: >
container.id != host and
(evt.type = setns or evt.type = unshare)
output: "Possible container escape attempt (process=%proc.name, pid=%proc.pid)"
priority: CRITICAL
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]Code language: YAML (yaml)This rule directly addresses the attack vector outlined in the CVE by focusing on privileged operations that could facilitate a container or VM escape.
Detecting privilege escalation via capabilities
Alternatively, we provide a custom rule to detect privilege escalation attempts inside a container or VM by checking processes that gain elevated capabilities, specifically CAP_SYS_ADMIN or CAP_SYS_PTRACE.
- rule: Privilege Escalation via New Capabilities
desc: Detects processes inside a container gaining extra capabilities
condition: >
container.id != host and evt.type = capset and
(evt.arg.cap = CAP_SYS_ADMIN or evt.arg.cap = CAP_SYS_PTRACE)
output: "Process gained elevated capabilities (process=%proc.name, cap=%evt.arg.cap)"
priority: HIGH
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]Code language: YAML (yaml)These capabilities are critical for system-level operations and can be exploited by an attacker to gain root-like privileges inside a container or VM. The rule is directly related to the CVE, as it helps identify attempts to escalate privileges before an attacker may execute a container escape, preventing further compromise of the host system.
Detecting exploits targeting the VMX process (specific to CVE-2025-22224)
Since this vulnerability exploits race conditions in ESXi’s VMX process, Falco can monitor for unwanted VMX activity. The below Falco rule monitors for activity involving the vmx process in VMware ESXi, which is responsible for virtual machine execution. It triggers an alert if the process is unexpectedly opened, written to, or executed, and the command line does not contain “expected_admin_task,” indicating a potentially malicious or abnormal modification.
- rule: Suspicious VMX Process Modification
desc: Detects unexpected changes to VMX processes in ESXi
condition: >
proc.name = "vmx" and evt.type in (open, write, execve) and
not proc.cmdline contains "expected_admin_task"
output: "Potential VM escape attempt targeting VMX process (cmdline=%proc.cmdline)"
priority: CRITICAL
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]Code language: YAML (yaml)The rule relates to CVE-2025-22224 by detecting attempts to exploit race conditions in the VMX process, which could allow an attacker to escape from the VM and gain access to the host system. By focusing on abnormal interactions with the VMX process, this rule helps identify and mitigate potential VM escape attempts.
Additional hardening measures: SELinux & KubeArmor
While Falco provides strong runtime detection, additional enforcement layers can prevent exploitation:
SELinux for Mandatory Access Control
- Enforces strict access control policies, preventing unauthorized processes from modifying hypervisor components.
- Can restrict VMX process modifications to only trusted users and processes.
KubeArmor for Kubernetes Enforcement
- Can actively block escape attempts by enforcing syscall restrictions at the container level.
- Complements Falco by preventing known attack patterns rather than just detecting them.
In the case of Kubernetes, KubeArmor is a cloud-native runtime security enforcement system that utilizes Linux Security Modules (LSMs) like SELinux (Security-Enhanced Linux) and AppArmor, alongside eBPF, to secure Kubernetes workloads, offering capabilities that go beyond simply setting security contexts in Kubernetes.
Since these ESXi hosts won’t always be tied to Kubernetes, users won’t always benefit from KubeArmor’s advantage of simplifying the complexity of LSMs and providing fine-grained runtime security for pods, containers, and nodes, including alerts and telemetry events. In those scenarios, we would recommend defining a custom SELinux module to restrict those syscalls, like so:
module vmx_escape_restrict 1.0;
require {
type vmx_t;
type sysctl_t;
class process { execmem execstack };
class syscall { setns unshare };
}
# Deny syscalls related to namespace manipulation for the vmx process
deny vmx_t self:syscall setns;
deny vmx_t self:syscall unshare;
# Allow other normal activities of the vmx process
allow vmx_t sysctl_t:process { execmem execstack };Code language: YAML (yaml)The above custom SELinux access control policy restricts the VMX process’s ability to perform potentially dangerous syscalls like setns or unshare, which are commonly used in container or VM escape attempts. By defining a custom SELinux policy, you can specifically limit the syscalls that VMX is allowed to make, thereby reducing the chances of a successful escape.
In the context of the above policy, vmx_t is the SELinux type for the VMX process in VMware ESXi, whereas syscall { setns unshare } are the actual system calls related to namespace manipulation that are commonly used in container or VM escape attempts. This policy denies these syscalls to the VMX process. We include process { execmem execstack } as the process permissions for normal execution for the VMX process. And finally, sysctl_t is the type for system control processes, allowing access to normal configuration without affecting security.
Once you’ve defined the SELinux policy in a file (ending with a .te file extension), you can compile and load it. However, before deploying any SELinux policy like this in a production environment, thoroughly test it in a staging environment to ensure it does not interfere with legitimate VMware ESXi functionality. This was provided as an example for limited syscall activity, but needs to be tested before production usage. Just like how we detected the same behaviour in our custom Falco rules, we can deny the setns and unshare syscalls for the VMX process with SELinux. The policy ensures that the VMX process cannot manipulate namespaces, which is a key technique in container and VM escape exploits.
Strengthening defenses against hypervisor escapes
CVE-2025-22224 represents a severe threat to cloud environments. Falco provides a critical detection layer, identifying VM and container escapes before attackers execute full exploitation. However, because Falco does not block syscalls pre-execution, pairing it with SELinux, KubeArmor, and robust patch management is essential.
Key takeaways:
- Falco detects early signs of escape attempts (e.g., namespace access, privilege escalation, suspicious VMX modifications).
- Falco does not block exploits pre-syscall execution. However, it enables real-time alerts and response automations via Falco Talon.
- Combining Falco with SELinux enhances enforcement, preventing the syscall activity.
- Immediate patching of ESXi vulnerabilities is critical to closing security gaps.
By leveraging Falco’s runtime detection, security teams can spot and stop escape attempts before they escalate into full hypervisor compromises. In a world where VM and container security is mission-critical, layered defense is the best strategy. If you like to read more about how Falco detects escape activity, we have published quite a few blogs on similar CVEs.