This path traversal in Zoom's VDI client warrants more scrutiny than the CVSS 7.1 score suggests—not because the score is wrong in isolation, but because VDI deployments create attack surface characteristics that CVSS wasn't designed to capture. The 'authenticated user' requirement likely refers to a valid VDI session credential, not the Zoom application account or host OS user. In VDI environments, this distinction matters enormously: the Zoom client sits at the intersection of Zoom's authentication layer and the hypervisor's isolation boundary, and the CVE language suggests Zoom may not have fully mapped what their client could access when bridging these two security domains.
The practical risk is lateral movement through a cascade that CVSS treats as separate base metrics. A path traversal reading a config file might expose session tokens. Those tokens might grant access to shared storage. Shared storage might touch cross-session state or host-level resources. In healthcare, financial, or government VDI deployments—common Zoom use cases—this means potentially accessing data from other sessions or sensitive infrastructure the attacker was never authorized to reach.
What to check: identify whether your Zoom deployment uses VDI infrastructure and which VDI platform (VMware, Citrix, etc.). Determine whether your Zoom VDI client is configured to mount host filesystems or shared storage, as this directly affects the traversal's reach. Verify whether your VDI sessions persist credentials or session tokens that could be harvested post-traversal. Most critically, recognize that patch deployment in VDI environments routinely takes 60-90 days due to host reboot requirements—meaning the window between patch availability and full remediation is substantially longer than standard applications, and the effective exposure period extends accordingly.