Tag Archives: Vulnerabilities

(3) ESXi Zero Day Vulnerabilities: CVE-2025–22224/22225/22226

Posted on by

Written By: Kevin Beaumont

March 4th, VMware quietly released patches for three ESXi zero day vulnerabilities: CVE-2025–22224, CVE-2025–22225, CVE-2025–22226.

Although the advisory doesn’t explicitly say it, this is a hypervisor escape (aka a VM Escape). A threat actor with access to run code on a virtual machine can chain the three vulnerabilities to elevate access to the ESX hypervisor.

This is backed up by VMware’s official Github, which says:

Yes, this is being actively exploited in the wild.

Once you have ESX access, you can access everything on the ESX server — which includes things such as VM data, and crucially ESX config and mounted storage. Using ESX config and mounted network storage, you can traverse the VMware environment.

My pretty diagram:

Feel free to use this carefully prepared graphic to brief your board or the public

For example, orgs use vMotion to allow virtual machines to automatically move across ESX hosts, to balance load and allow for maintenance without downtime (it’s how VMware security patching works). Because of this, a threat actor has direct access to storage of VMs both on and not on that host by design — they’re basically loose on the backend.

Areas of concern

ESXi is a ‘black box’ environment, where you don’t have EDR tools and such — it is locked down. As such, a hypervisor escape means a threat actor is outside of all security tooling and monitoring. They can, for example, access Active Directory Domain Controller databases without triggering any alerts anywhere in the stack, or delete data.

This is frequently seen in ransomware incidents, where people directly exploit the ESX server or vCenter server over the VMware management network using unpatched vulnerabilities. Once they reach ESX, they reach directly into storage across the whole cluster.

However, being able to reach the ESX server hypervisor directly from the Virtual Machine significantly raises the risk. For example, you don’t need to find the ESX server details, or reach a segregated network.

‘But Kevin’ you may say ‘if a threat actor gained access to a VM it’d be game over’. Well… not so much. Threat actors gain access to endpoints all the time in any large org, e.g. malware initial access on end user PCs. When you have VDIs on VMware, you have a problem. When you have shared servers on VMware, you have a problem. Compromise one of system in a company is not usually a big problem in the short term. Immediate compromise of all of them is a big problem.

Additionally, there are around 500 Managed VMware providers, who operate as effectively clouds, allowing SMBs to purchase fully managed VMs, on demand compute basically. A compromise of one customer VM would allow compromise of every customer VM in the same managed provider.

This also applies to companies who have built their own Private Clouds using VMware, and use VMware to segregate business units.

Versions impacted

The Broadcom advisory is currently incomplete for some reason. For example VMware’s Github lists versions 6.5 and 6.7 as impacted, and patches are available on VMware’s website — but VMware’s advisory on the Broadcom site doesn’t list them as impacted as of writing. Basically, every release of ESX is impacted.

I understand 5.5 is also impacted, however it is out of support so no patch is available.

Continue reading article here!

Understanding CVE-2025-1094: PostgreSQL Exploit Risks (US Treasury)

Posted on by

A high-severity SQL injection bug in the PostgreSQL interactive tool was exploited alongside the zero-day used to break into the US Treasury in December, researchers say.

Rapid7’s principal security researcher, Stephen Fewer, disclosed CVE-2025-1094 (8.1) on Thursday, saying it was a key part of the exploit chain that also included the BeyondTrust zero-day (CVE-2024-12356).

In fact, CVE-2025-1094 was so important to the chain that the BeyondTrust attack couldn’t have been pulled off without it, we’re told.

“Rapid7 discovered that in every scenario we tested, a successful exploit for CVE-2024-12356 had to include exploitation of CVE-2025-1094 in order to achieve remote code execution,” said Fewer.

“While CVE-2024-12356 was patched by BeyondTrust in December 2024, and this patch successfully blocks exploitation of both CVE-2024-12356 and CVE-2025-1094, the patch did not address the root cause of CVE-2025-1094, which remained a zero-day until Rapid7 discovered and reported it to PostgreSQL.”

According to Rapid7’s director of vulnerability intelligence, Caitlin Condon, CVE-2025-1094 affects all versions of the PostgreSQL interactive tool, but, fortunately, it isn’t particularly simple to exploit. Given the complexity of the exploit pattern, Rapid7 doesn’t expect attacks to be carried out away from the BeyondTrust versions already known to be vulnerable.

She said via Mastodon: “But with the above said, it’s clear that the adversaries who perpetrated the December attack really knew the target technology, which is yet another example of a zero-day exploit trend Rapid7 started tracking in 2023.”

The vulnerability in the PostgreSQL interactive tool (psql) can lead to arbitrary code execution (ACE) and there is also a technique to exploit it independently from CVE-2024-12356. Rapid7 said BeyondTrust’s patch for its zero-day didn’t address the root cause of the psql bug, but it does prevent the two from being exploited together.

The psql vulnerability can be exploited because of an incorrect assumption that a SQL injection attack can’t be carried out when a malicious input is safely escaped via PostgreSQL’s string escaping routines, Fewer said.

Source Article:

https://www.theregister.com/2025/02/14/postgresql_bug_treasury/?utm_source=tldrinfosec