Ransomware is exploiting a critical VMware flaw: what to check today on the virtualized servers of your Mexico operation
On September 15, 2026, CISA, the US cybersecurity agency, confirmed that ransomware gangs are actively exploiting a critical remote code execution flaw in VMware vCenter, as BleepingComputer reported. In plain terms: whoever reaches your vCenter can take over every virtual server that hangs from it.
If you run a plant, a warehouse or an office in Mexico from abroad, this one deserves a call today. In our experience, the local ERP, the file server and often the domain controller live as virtual machines on an ESXi host that a local integrator installed years ago. Nobody at headquarters knows the version, and nobody has patched it since.
Why one hole in vCenter takes down the whole site
Quick primer. ESXi is the system that turns one physical server into several virtual servers, the VMs. vCenter is the console used to manage all those ESXi hosts at once.
That is exactly why ransomware crews love it. They do not need to break into machines one by one. They take the console, power off the VMs and encrypt the whole disks in one go. Monday morning the accountant in Querétaro cannot open the ERP, the front desk has no email and the plant cannot print work orders.
First: find out which version is running in Mexico
Ask whoever has the credentials to open the vCenter web console and read the version and build number under Help, About. On ESXi, the host home page shows it at the top. Get a screenshot, not a verbal answer.
Then compare it against the Broadcom security advisory (Broadcom owns VMware). If your build is older than the fix, you are exposed. If the integrator who installed it no longer answers the phone, you are exposed and in a hurry.
A rule we repeat a lot: if nobody can tell you when it was last patched, assume never.
vCenter and ESXi must never face the internet
This is the most important part of the article. From your laptop abroad, on a normal connection, try the public IP of the Mexico site. If a VMware login page shows up, you have a problem today, patch or no patch.
The virtualization console gets managed over VPN or from a separate internal network. Full stop. And while you close that door, make sure the backup server does not depend on the same vCenter you are trying to protect.
Backup, snapshot, then patch, in that order
A snapshot is a picture of a VM at a point in time that lets you roll back in minutes. It is not a backup: if the physical disk gets encrypted, the snapshot goes with it.
| Step | What happens | Downtime |
|---|---|---|
| 1. Full backup | Copy critical VMs off the host and test a restore | None |
| 2. Snapshot | Snapshot vCenter and each ESXi before the change | None |
| 3. Patch vCenter | Goes first because it is the console | Minutes without console, VMs keep running |
| 4. Patch ESXi one by one | Move VMs to the other host, patch, move back | None with two hosts; a night window with one |
| 5. Verify and delete snapshots | Confirm new version and clean up | None |
With a single host, schedule the window at night in Mexico time and tell the local team. VMs go down for minutes, not hours. How to get backups that actually restore is in backups that restore after ransomware in Mexico.
Signs someone is already inside
Patching closes the door but does not evict anyone already in. Check these before you call it done:
- New users in vCenter or ESXi that nobody created.
- Active SSH sessions on ESXi when nobody is working on it.
- Snapshots or VMs you do not recognize, especially with odd names.
- Recent scheduled tasks or scripts on the host.
- Backups that stopped running or were deleted without notice.
What about your Mexico operation?
If reading this you could not say which ESXi version runs at your Mexico site or when it was last patched, that is the assessment. It is nobody’s fault: servers that work do not get attention until they stop.
At ProcessBi we review servers and virtualization, schedule patching inside a support plan with a written SLA, and test that backups really restore. We have hands on site across Mexico, in Spanish and English, so your headquarters gets a report and the local team gets a technician.
Ask for a server review — we reply the same business day.
Your path
Running IT in Mexico from abroad
13 of 32- Smart hands ✓ Read You are here 2 min
- Remote support ✓ Read You are here 3 min
- Nearshoring checklist ✓ Read You are here 2 min
- Retail rollouts ✓ Read You are here 2 min
- Fake IT support ✓ Read You are here 3 min
- Backups that restore ✓ Read You are here 3 min
- Secure M365 ✓ Read You are here 3 min
- Windows 10 deadline ✓ Read You are here 4 min
- Audit app access ✓ Read You are here 3 min
- CEO fraud ✓ Read You are here 4 min
- Office 2016 cutoff ✓ Read You are here 3 min
- Patch today ✓ Read You are here 4 min
- Patch VMware ✓ Read You are here 4 min
- Office 2021 EOL ✓ Read You are here 3 min
- Starlink for sites ✓ Read You are here 3 min
- Cardless access ✓ Read You are here 4 min
- Control AI on PCs ✓ Read You are here 4 min
- ScreenConnect flaw ✓ Read You are here 4 min
- Server 2022 EOL ✓ Read You are here 3 min
- Exposed cameras ✓ Read You are here 3 min
- Domain trust fix ✓ Read You are here 4 min
- Patch Cisco ISE ✓ Read You are here 3 min
- Protect the plant ✓ Read You are here 3 min
- Move to 25H2 ✓ Read You are here 4 min
- Outages and UPS ✓ Read You are here 3 min
- IT maintenance ✓ Read You are here 4 min
- Third-party scripts ✓ Read You are here 3 min
- License audit ✓ Read You are here 4 min
- Bajío fiber corridor ✓ Read You are here 3 min
- Check Point flaw ✓ Read You are here 4 min
- Cashless payments ✓ Read You are here 3 min
- AI that hacks alone ✓ Read You are here 3 min
- Field services →