CVE-2026-63622 PUBLISHED

Libvirt: swtpm privilege escalation via symlink following

Assigner: redhat
Reserved: 17.07.2026 Published: 10.08.2026 Updated: 10.08.2026

A flaw was found in libvirt. A local attacker, specifically a process running as the confined swtpm user, could exploit a symlink-following vulnerability in the virFileChownFiles() function. By planting a symbolic link within the swtpm state directory, the attacker could trick the root-level libvirt daemon into changing the ownership of an arbitrary file to the swtpm user. This allows for privilege escalation from the swtpm sandbox to root-level file ownership control.

Metrics

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8

Product Status

Vendor Red Hat
Product Red Hat Enterprise Linux 10
Versions Default: affected
Vendor Red Hat
Product Red Hat Enterprise Linux 6
Versions Default: unaffected
Vendor Red Hat
Product Red Hat Enterprise Linux 7
Versions Default: affected
Vendor Red Hat
Product Red Hat Enterprise Linux 8
Versions Default: affected
Vendor Red Hat
Product Red Hat Enterprise Linux 9
Versions Default: affected
Vendor Red Hat
Product Red Hat Enterprise Linux for NVIDIA 26
Versions Default: unknown

Workarounds

If virtual Trusted Platform Module (vTPM) functionality is not required, remove the <tpm> device definition from the domain XML configuration to prevent the vulnerable code path from being reached.

To check if a domain uses vTPM: virsh dumpxml <domain> | grep -A5 '<tpm'

To remove it, edit the domain XML and delete the <tpm> block. This prevents libvirt from spawning swtpm processes and from calling virFileChownFiles() on the swtpm state directory during domain startup. Domains that require vTPM for guest OS functionality cannot use this mitigation and should prioritize applying the upstream fix.

Credits

  • Red Hat would like to thank HE WEI (gikaku) for reporting this issue.

References

Problem Types

  • Improper Link Resolution Before File Access ('Link Following') CWE