If your business runs Zoom on Windows, patch it this week, not next month. Zoom has fixed a critical flaw, now widely reported as the Zoom account takeover vulnerability (CVE-2026-53412). It let an attacker seize a user’s account with no password and no existing session. The victim did not need to click anything. Here is what happened, whether you are affected, and exactly what to do about it.
Table of Contents
What actually happened
On 14 July 2026, Zoom published security bulletin ZSB-26014 about the Zoom account takeover vulnerability. It describes an “improper input validation” flaw allowing an unauthenticated user to take over an account via network access. Zoom revised the bulletin the following day to narrow the affected product list.
The bug scores 9.8 out of a possible 10 on the CVSS severity scale. That is the range reserved for flaws needing no credentials, no special access and no user interaction.
Put simply, an attacker on the network did not need to trick anyone or steal a password first. That pushes it into “patch immediately” territory, not the normal patch cycle.
Am I affected by the Zoom account takeover vulnerability?
Check whether your business runs either of these, and at what version.
- Zoom Workplace for Windows. Vulnerable before version 7.0.0.
- Zoom Workplace VDI Client for Windows. Vulnerable before version 7.0.10, 6.6.15 or 6.5.18, depending which branch you run.
Zoom’s first bulletin also listed the Meeting SDK for Windows as affected. The 15 July revision removed it. If your developers embed the Meeting SDK in an internal tool, check the current bulletin directly. Don’t rely on the earlier reports still circulating.
Mac, Linux and mobile Zoom clients are not named in this bulletin. This is a Windows-specific issue.
What to do, in order
- Update Zoom Workplace for Windows on every device, via the Zoom download centre or your deployment tool.
- Update the Workplace VDI Client for Windows separately. It ships and updates independently of the desktop client.
- Check your VDI golden images. If the VDI client is baked into a master image, updating individual sessions will not help. Patch and redeploy the image itself.
- Check Zoom Rooms hardware and shared meeting-room PCs. Nobody is logged in to see an update prompt on these, so they are easy to miss.
- Confirm the patch landed. Don’t assume an automatic update ran. Spot-check version numbers, especially on devices that have been offline or in standby.
While you are in there, Zoom also patched three related high-severity bugs the same day. They cover a race condition during install or uninstall (CVE-2026-53410), a privilege management flaw in Zoom Rooms for Windows (CVE-2026-53409), and an input validation issue in the Workplace VDI Plugin (CVE-2026-53411). All three need an attacker who already has a foothold on the machine. That makes them less urgent than the account takeover bug, but the same update resolves them, so there is no reason to leave them for later.
Is this actively being exploited?
As of writing, Zoom says it has no evidence of active exploitation. Zoom’s own Offensive Security team found the bug, rather than an outside researcher or an incident response team. That is genuinely reassuring, but not a reason to slow down. Once a flaw like the Zoom account takeover vulnerability goes public, the window before opportunistic scanning begins is typically short.
Common questions
Do I need to reset passwords after patching? Zoom has not asked customers to force password resets, and there’s no evidence of exploitation. A mass reset is not required. If you think a specific account was targeted, treat it individually and check sign-in activity for that user.
Does this affect Zoom on Mac or mobile? No. The bulletin names Windows clients only: Zoom Workplace for Windows and the Workplace VDI Client for Windows. Mac, Linux, iOS and Android builds are not listed as affected.
What if we manage Zoom through Intune or SCCM rather than letting users update themselves? Push the update through your normal deployment channel, as you would for any other application. Treat it with the urgency of an operating system critical patch, not the next scheduled software cycle.
We use a third-party Zoom Rooms hardware appliance. Does the vendor patch that for us? Usually yes, but confirm rather than assume. Ask the hardware vendor or reseller whether their firmware bundles the fixed Zoom Rooms build, and get a date.
The wider lesson from the Zoom account takeover vulnerability
Zoom is one app among dozens most businesses run. It’s a useful test case. Does your patch process actually reach third-party desktop software, or does it stop at the operating system? A laptop can show a fully patched Windows build and still run a Zoom client from eight months ago. Nobody folded it into the same update cadence.
If you are not sure how your business would answer that question, a vulnerability assessment or network penetration test will find out. It will also catch the next application that quietly falls through the same gap.
