Skip to main content

VSA-2026-044: Privilege Escalation to Global Administrator via Prototype Pollution through Attacker-Controlled VMware VMX in vm.importFromEsxi

PublishedUpdatedSeverityCVSS 4.0Affected products
2026-09-302026-09-30🔴 ImportantNot available yet- Xen Orchestra / Xen Orchestra Appliance
info

A vulnerability was discovered in Xen Orchestra that is part of the Xen Orchestra Appliance. We classify the impact as Important. For details on how we assign severity levels, see our Severity Levels Explained page.

Summary​

The API methods vm.importFromEsxi and vm.importMultipleFromEsxi are registered without any permission or resolve declaration, so they are callable by any authenticated user with zero ACL checks. They make xo-server connect to an attacker-controlled ESXi/vCenter host and parse an attacker-controlled VMware .vmx file. The VMX parser performs prototype pollution: a .vmx line __proto__.permission = "admin" sets Object.prototype.permission = "admin" process-wide.

Status​

  • Released

Impact​

An unprivileged user ("permission": "none") can escalate their privileges and perform actions restricted to the admin role.

Affected Versions​

  • Before Xen Orchestra version 6.9.0.

Mitigations​

info

Security fixes are delivered to the latest channel before the stable channel. Switching to latest therefore allows earlier remediation, although this channel may be less stable.

Several mitigation options are available. Select the one best suited to the deployment context and stability requirements.

Unload the VDDK library. Note that this will disable the v2v feature.

  1. Remove the directory containing VDDK_LIB in VDDK_LIB_PATH:
cd /usr/local/lib/vddk
rm -rf vmware-vix-disklib-distrib
  1. Restart xo-server service:
systemctl restart xo-server

For a Xen Orchestra instance that requires high stability, the patch can be applied manually on the latest version of stable channel.

Patch file : vsa-2026-044.patch

  1. Copy the patch in /tmp directory and go to /usr/local/lib/node_modules directory:
cp vsa-2026-044.patch /tmp
cd /usr/local/lib/node_modules
  1. Verify the integry of the patch by checking the checksum b29657a38738522cc55194a707f155dc4f009d709ad480058f99ab8020586806:
sha256sum /tmp/vsa-2026-044.patch
b29657a38738522cc55194a707f155dc4f009d709ad480058f99ab8020586806  /tmp/vsa-2026-044.patch
  1. Check if the patch apply to XOA:

This output should appear.

patch -p1 --dry-run  < /tmp/vsa-2026-044.patch

patching file xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs
patching file xo-server/node_modules/@xen-orchestra/vmware-explorer/parsers/vmsd.mjs
patching file xo-server/node_modules/@xen-orchestra/vmware-explorer/parsers/vmx.mjs
patching file xo-server/dist/api/user.mjs
patching file xo-server/dist/api/vm.mjs
Hunk #1 succeeded at 1512 (offset -15 lines).
Hunk #2 succeeded at 1636 (offset -15 lines).
patching file xo-server/dist/models/user.mjs
  1. Apply the patch:
patch -p1 < /tmp/vsa-2026-044.patch
  1. Check the syntax:
node --check xo-server/dist/api/vm.mjs 
node --check xo-server/dist/api/user.mjs 
node --check xo-server/dist/models/user.mjs
node --check xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs
node --check xo-server/node_modules/@xen-orchestra/vmware-explorer/parsers/vmsd.mjs
node --check xo-server/node_modules/@xen-orchestra/vmware-explorer/parsers/vmx.mjs
  1. Restart xo-server service:
systemctl restart xo-server

Resolution​

As of 2026-09-30, Xen Orchestra version 6.9.0 has been released and includes the fix for this issue. It is currently available on the latest channel and should become available on stable in the next version in about a month.

List of packages fixing this issue:

  • xo-server: version 5.210.0
  • @xen-orchestra/vmware-explorer: 1.0.0

Credits​

Discovered by Allan Victor

References​