Libvirt: swtpm privilege escalation via symlink following (CVE-2026-63622)

Why this deserves its current priority

CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Red Hat/libvirt (generic), Red Hat/virt:rhel/libvirt (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Red Hat/libvirtgeneric	*	Not reported
Red Hat/virt:rhel/libvirtgeneric	*	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Red Hat/libvirt, Red Hat/virt:rhel/libvirt.
Review the reported fix. Source-reported workaround: 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.

Evidence timeline and material changes

Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Nov 4, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Aug 10, 2026

Sources and claim methodology

Upstream source description

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.

Quoted source text, attributed separately from HOL analysis.

Libvirt: swtpm privilege escalation via symlink followingCVE-2026-63622