Broadcom patched a critical VMware ESXi VM escape flaw (CVE-2026-47876) that could let attackers run code on the host from a compromised virtual machine.
Broadcom has released patches to address five vulnerabilities affecting VMware ESXi, vCenter, Workstation, and Fusion, including three rated critical. The most severe, tracked as CVE-2026-47876 (CVSSv3 base score of 9.3), is a VM escape flaw in the VMXNET3 virtual network adapter. An attacker with administrator privileges inside a virtual m
Broadcom patched a critical VMware ESXi VM escape flaw (CVE-2026-47876) that could let attackers run code on the host from a compromised virtual machine.
Broadcom has released patches to address five vulnerabilities affecting VMware ESXi, vCenter, Workstation, and Fusion, including three rated critical. The most severe, tracked as CVE-2026-47876 (CVSSv3 base score of 9.3), is a VM escape flaw in the VMXNET3 virtual network adapter. An attacker with administrator privileges inside a virtual machine could exploit it to execute arbitrary code on the underlying ESXi host.
“VMware ESX contains an out-of-bounds write vulnerability in the VMXNET3 virtual network adapter. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.3.” reads the advisory. “A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.”
Broadcom also fixed a critical vCenter authentication bypass, tracked as CVE-2026-59309 (CVSSv3 base score of 9.8), that can be exploited to gain unauthorized access to the targeted system.
“VMware vCenter contains an authentication bypass vulnerability in the VMware Directory Service. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.” reads the advisory. “A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system.”
The third critical issue fixed by the company is CVE-2026-59310 (CVSSv3 base score of 9.8), a flaw allowing an attacker with network access to execute arbitrary code.
“VMware vCenter contains a directory traversal vulnerability in the Syslog server. Broadcom has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.”states the advisory.”A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.”
The vendor also patched CVE-2026-41703 (CVSSv3 score of 7.6), a high-severity flaw affecting VMware ESXi, Workstation, and Fusion that could allow an attacker with VM deployment permissions to disclose information or cause a denial-of-service on the host. Another issue, CVE-2026-41709 (CVSSv3 score of 7.6), lets an administrator perform certain actions on ESXi without logging in. Although no active exploitation has been reported, Broadcom urges customers to apply the updates promptly.
Introduction
The new GenieLocker ransomware family has been active since March 2026. It has been used in attacks against organizations in the Russian Federation, primarily in the manufacturing sector, and attributed to the Toy Ghouls group by open-source intelligence (link in Russian).
The Toy Ghouls, also known as Bearlyfy, Labubu and Laboo.boo, is a financially motivated extortion group, which previously relied on third-party encryption Trojans like RedAlert, LockBit, and Babuk. GenieLocker, a
The new GenieLocker ransomware family has been active since March 2026. It has been used in attacks against organizations in the Russian Federation, primarily in the manufacturing sector, and attributed to the Toy Ghouls group by open-source intelligence (link in Russian).
The Toy Ghouls, also known as Bearlyfy, Labubu and Laboo.boo, is a financially motivated extortion group, which previously relied on third-party encryption Trojans like RedAlert, LockBit, and Babuk. GenieLocker, apparently a custom design, upgrades their toolkit and reduces their reliance on third-party software. We discovered multiple samples of this Trojan in two variants: PE builds for Windows and ELF builds for Linux and ESXi.
Technical details
Modus operandi
We described typical TTPs and modus operandi of the Toy Ghouls threat actor in the previous post (link in Russian).
In this article, we aim to thoroughly describe the capabilities of Windows and Linux builds of the custom encryption Trojan GenieLocker. To give more context, we will also provide a brief overview of the attack that took place at the end of March 2026, where GenieLocker was deployed on the victim’s systems.
Initial Access
During the incident, the attackers first entered the environment through an OpenVPN connection originating from an external partner’s network. They likely exploited the trusted relationship with that partner and used stolen, yet still valid, credentials to connect.
Discovery and Credential Access
After breaching the target’s network, the attackers installed additional tools on the compromised hosts, including OpenSSH, socks5.exe, SoftPerfect Network Scanner, and Mimikatz. They employed SoftPerfect Network Scanner for discovery and used Mimikatz to dump credentials. Forensic analysis also shows that they accessed the KeePassXC password manager already installed on several compromised machines, likely attempting to extract the stored credentials from the KeePass databases.
Lateral Movement and Command and Control
Lateral movement was performed by using RDP to reach Windows machines and SSH for Linux servers. The widespread deployment of the encryption Trojan was conducted with the legitimate utilities PsExec and PAExec. Additionally, the attackers established a reverse SSH tunnel to communicate with their command‑and‑control server.
Impact
During the impact phase, the attackers encrypted files on the compromised Windows machines with the PE version of the GenieLocker ransomware. On the compromised Linux and ESXi servers, they stopped active virtual machines and encrypted their disks using the ELF version of GenieLocker.
The tactics, techniques, and procedures seen here match those documented in earlier attacks attributed to the Toy Ghouls group. As in those prior incidents, forensic analysis found no evidence of data exfiltration, which is typical behavior for this threat actor. Toy Ghouls have not employed a double‑extortion model and do not run a data‑leak website.
Encryption Trojan for Windows
The Windows version of GenieLocker (MD5: 5d62c1349b8981c396c9a23f4f8f053c) is primarily written in C, but compiled with the C++ libraries using Microsoft Visual C/C++. The malware incorporates several ransom‑related capabilities, including process termination, service shutdown, debugger evasion, and a sophisticated encryption routine. For its cryptographic operations, it relies on the open‑source libsodium library.
Aligned with the recent trend supported by our expertise, as observed in attacks of some other ransomware strains, GenieLocker doesn’t save the ransom notes on the victim’s system. The Trojan doesn’t contain any attackers’ contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack. This approach may be an attempt by the GenieLocker developers to avoid proactive detection of the ransomware process being triggered by the creation of multiple readme files.
GenieLocker help message
Arguments and launch
GenieLocker supports multiple arguments for configuring its behavior.
Argument
Description
First argument
“Secret” argument, hex string value
-p, –percent N
Percentage of file content to encrypt
-r, –recursive
Process directories recursively
-l, –log <filename>
Set path for log file
-h, –help
Show help message
Last argument
Path to encrypt
GenieLocker expects the first argument to be a hex string referred to in the malware code as the “secret argument”, which is required for the ransomware to start. Most likely, the purpose of this is to avoid execution on sandboxes and other automated analysis environments. Another reason may be to prevent unauthorized usage by other threat actors.
Checking the secret argument
The secret argument is a hex value with a variable size that does not exceed 4096 bytes. This hex string value is converted to bytes and hashed with the SHA‑256 algorithm. The result is compared to a hardcoded value. If they match, the literal string session is appended to the secret value, and the whole string is hashed with BLAKE2b‑256, but the resulting hash is never used. This may be a part of a feature still in development.
Secret value hashing
Anti-debugging
GenieLocker contains multiple methods to inspect if its process is under debugging. After launch it makes the first check named Environment check and uses WinAPI functions IsDebuggerPresent and CheckRemoteDebuggerPresent to detect the debugger.
Environment check
After the secret argument validation, GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.
Watchdog checks
The only thing worth elaborating on is that the GenieLocker process calculates the CRC32 of its .text section when the watchdog thread is starting, saves the resulting hash, and then recalculates it again in every loop and compares with the initial value. In case the code in this section is modified by the debugger or other program, this method allows the Trojan to detect this modification.
Preparing for encryption
GenieLocker contains multiple exclusion lists. For example, it does not encrypt folders with names from the list below. Among those, there are mostly system folders, which are skipped to avoid corrupting the OS.
Furthermore, the Trojan contains an exclusion list for host names. The malware retrieves the computer name using GetComputerNameA and checks it against this list, but in the sample in question, the list is empty.
Output for whitelisted hosts
If the host name is not excluded, GenieLocker starts to kill processes that could be using the files of interest and therefore prevent the Trojan from encrypting them. These processes are listed below. The Trojan stops them by using the TerminateProcess function.
Finally, GenieLocker starts encryption threads and searches for all available drives, including network shares, to encrypt them.
Threads info output
File encryption and cryptography
The extension for the encrypted files is hardcoded in the Trojan’s body. In the sample under review, it is .03ffc1c4a3da0f02. Before starting to encrypt each file, GenieLocker creates two auxiliary files:
a lock file: <filename.fileext>.03ffc1c4a3da0f02.lock
a journal: <fileext>.03ffc1c4a3da0f02.journal
The lock file helps to protect files from double encryption by other threads or instances. Inside this file, the Trojan stores the current PID obtained from the GetCurrentProcessId function.
The journal file contains the hardcoded string VCJOURN, value 1 (possibly version), some unused zeroed fields, total blocks to encrypt, and the count of blocks that are actually encrypted. The last field is a CRC32 hash sum for the integrity check of the journal content.
Journal content
By default GenieLocker encrypts files using 0x1000000-byte chunks. If the argument -p is passed (it sets the percentage of the file contents to be encrypted), the ransomware calculates how many chunks with 0x1000000 size are necessary to encrypt the specified percentage. Each chunk has a random position inside the file. Regardless of whether the percentage is set, even if it is zero, the first chunk in the beginning of the file will be encrypted anyway.
The Trojan encrypts the file content using the Authenticated Encryption with Associated Data (AEAD) algorithm XChaCha20-Poly1305, with a unique key and nonce for each file. The Trojan also adds a footer that contains the data necessary for future decryption and metadata. The metadata parts are encrypted using the same cipher and key as the file contents, but with a different nonce. The file key is encrypted using the Curve25519-XSalsa20-Poly1305 scheme, with the attackers’ master public key hardcoded in the Trojan’s body.
The metadata of each encrypted file contains the following fields.
Value or name
Size (bytes)
Description
version
1
Hardcoded byte with value 1, most likely the version.
encryption_percent
1
Percentage of file content to encrypt, value from -p argument.
file_nonce
24
Nonce used during encryption of the file content.
original_filesize
8
Original size of the file before encryption.
total_chunk_count
8
Max count of chunks inside the current file.
chunk_size
4
Size of a single encrypted chunk (by default, 0x1000000 bytes on Windows and 0x400000 on ESXi and Linux).
remain_size
4
The number of bytes remaining after splitting the file content into chunks.
blake2b_digest_of_chunks
32
BLAKE2b-256 hash calculated from the original data of all chunks before they are encrypted. Used for integrity checks.
chunk_count
4
Number of chunks that were encrypted.
extension
64
A string with the additional ransomware extension.
poly1305_tags (array)
16 bytes per chunk
Array of Poly1305 tags of encrypted chunks.
bitmask
varies, one bit per each chunk
Chunks bitmask; if set, the chunk is encrypted; otherwise, it is not.
The chunks bitmask contains as many bits as the maximum number of chunks inside a file at 100%. If a bit at a specific index is set to 1, the chunk is encrypted. The value 0 means that the chunk is not encrypted. Since the Trojan encrypts files based on the percentage value, it needs to know which chunks were encrypted.
Metadata structure at the end of an encrypted file (without a Poly1305 tags array or bitmask)
Encryption Trojan for ESXi and Linux
Compared with its Windows counterpart, the Linux and ESXi version of GenieLocker (MD5: 9201e35e2993612612919a3c71302cab) is simpler: there is no secret argument, anti‑debugging techniques, or exclusion lists. However, the sample has ESXi-specific features, such as double‑fork support and the ability to modify the Welcome Message. The sample has the version v1 and, similarly to the Windows version, uses the libsodium library for cryptography.
ESXi version description
The command‑line help output mirrors LockBit’s styling, reinforcing the theory that GenieLocker’s creators set out to craft a LockBit‑style replacement for their own operations.
LockBit output design, possibly the source layout for the GenieLocker ESXi variant
Based on the default path of the encryption directory /vmfs/volumes, we can assume that this version is intended primarily for ESXi. Nonetheless, it can still be executed on Linux distributions.
Argument
Description
-p <perc>
Percentage of file content to encrypt
-j <workers>
Number of encryption threads
-r <dir>
Process directories recursively
-w <sec>
Delay before start
-d
Daemonizing the process
-l <logfile>
Path to log file
ESXi and Linux features
This build allows daemonizing its process with the -d flag, employing the classic double‑fork method so the new process becomes fully detached from its parent.
This variant also modifies the /etc/vmware/welcome file, which contains the Welcome Message (Message of the Day) on the ESXi operating system. On Linux distributions, it does not change anything, because they use different paths for the Message of the Day. In the GenieLocker sample examined here, the message is left empty.
Additionally, the ESXi version supports a few basic features that are not included in the Windows version. For instance, there is a launch‑delay option and the ability to set the number of encryption worker threads. This build also includes several features that already exist in the Windows variant, such as configuring the percentage of a file to encrypt, choosing the target directory, and setting the log file location.
File encryption
The encryption scheme for files is identical to the Windows version. The Trojan uses XChaCha20-Poly1305 to encrypt the file content and metadata, and Curve25519-XSalsa20-Poly1305 for key encryption.
File encryption summary
Victims
According to KSN telemetry, GenieLocker detections are overwhelmingly concentrated on endpoints located in the Russian Federation. In the March 2026 campaign, the primary sector under siege was manufacturing, with construction trailing closely, followed by financial services, retail, and technology.
Conclusions
Toy Ghouls are ramping up their campaign against Russian enterprises. The rollout of their home‑grown encryption Trojan GenieLocker marks a major upgrade to the group’s ransomware toolkit. By engineering bespoke ransomware that runs natively on Windows, Linux, and ESXi, the actor has cut their dependence on off‑the‑shelf ransomware families and unified the cryptographic backbone across all targeted platforms.
Kaspersky’s products detect this malware as Trojan-Ransom.Win64.Agent.genie, HEUR:TrojanRansom.Win64.Generic, Trojan-Ransom.Linux.Agent.genie.
Entrar
