CVE-2026-77159: libvirt Symlink Privilege Escalation

CVE-2026-77159 Overview

A symlink-following flaw exists in libvirt's qemuTPMEmulatorPrepareHost() function. The function performs a path-based chown() on the swtpm logfile without verifying whether the target is a symbolic link. A local attacker with access to the swtpm account can replace the logfile with a symlink pointing to an arbitrary file. When libvirtd runs the chown() as root, ownership of the attacker-chosen file transfers to the swtpm user. This flaw is tracked under [CWE-61: UNIX Symbolic Link (Symlink) Following].

Critical Impact
A local attacker controlling the swtpm account can hijack ownership of arbitrary files on the host, undermining file integrity and enabling privilege escalation paths.

Affected Products

libvirt (upstream project maintained by the libvirt community)
Red Hat distributions shipping libvirt with the swtpm TPM emulator integration
Any Linux distribution packaging vulnerable versions of libvirt with QEMU TPM emulator support

Discovery Timeline

2026-09-11 - CVE-2026-77159 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-77159

Vulnerability Analysis

The flaw resides in libvirt's QEMU TPM emulator preparation logic. When libvirt sets up the swtpm environment for a virtual machine, qemuTPMEmulatorPrepareHost() adjusts ownership of the swtpm logfile so the swtpm process can write to it. The function calls chown() on the logfile path while running with root privileges inside libvirtd.

The path-based chown() operation follows symbolic links by default. If the target path is a symlink at the moment of the call, the kernel modifies ownership of the link target rather than the link itself. Because libvirtd does not open the file with O_NOFOLLOW or use lchown() and does not verify the file type before the operation, an attacker controlling the swtpm account can substitute the logfile with a symlink to any file on the system.

The result is a local integrity violation: ownership of sensitive host files such as /etc/shadow, cron configuration, or systemd unit files can be transferred to the swtpm user. This provides a stepping stone toward broader privilege escalation.

Root Cause

The root cause is the absence of symlink-safe file operations in qemuTPMEmulatorPrepareHost(). The code trusts that the logfile path resolves to a regular file owned by the expected user. It does not use fchown() on a file descriptor obtained with O_NOFOLLOW, nor does it perform a lstat() check to reject symbolic links before invoking chown().

Attack Vector

Exploitation requires local access as the swtpm user or another account with write access to the swtpm log directory. The attacker deletes or renames the existing logfile and creates a symbolic link at the same path pointing to a target file owned by root. When libvirtd next calls qemuTPMEmulatorPrepareHost() during VM startup, the chown() follows the link and reassigns ownership of the target to the swtpm user. The attacker can then modify the file directly.

No verified public exploit code is available. See the Red Hat CVE Advisory and GitLab Work Item #909 for upstream technical details.

Detection Methods for CVE-2026-77159

Indicators of Compromise

Unexpected ownership changes on system files where the owner has switched to the swtpm user or group
Presence of symbolic links in the swtpm log directory (commonly under /var/log/swtpm/libvirt/qemu/) pointing to files outside that directory
Deletion or replacement of swtpm logfiles immediately preceding a VM start operation

Detection Strategies

Audit filesystem operations performed by libvirtd using auditd rules that log chown and fchownat syscalls originating from the libvirtd process
Monitor creation of symbolic links inside directories writable by the swtpm account, correlating events with subsequent VM lifecycle actions
Baseline ownership of critical system files and alert when the owning UID changes to the swtpm service account

Monitoring Recommendations

Enable Linux audit rules covering the swtpm log directory and libvirt state directories for symlink creation and file replacement
Ingest libvirt and swtpm logs into a centralized logging platform and alert on VM start events followed by permission changes on non-VM paths
Track service account activity for swtpm, flagging any interactive shell usage or unexpected file operations outside its assigned directories

How to Mitigate CVE-2026-77159

Immediate Actions Required

Apply vendor-supplied updates for libvirt as soon as your distribution publishes patched packages
Restrict access to the swtpm account and audit which local users or containers can assume that identity
Review ownership of sensitive system files and revert any unauthorized changes traced to the swtpm user

Patch Information

The upstream fix is tracked in GitLab Work Item #909. Distribution-specific patch status is available via the Red Hat CVE Advisory and Red Hat Bug Report. Administrators should apply libvirt updates from their vendor repositories once released.

Workarounds

Prevent unprivileged users from writing to the swtpm log directory by tightening directory permissions and ownership
Mount the swtpm log directory with nosymfollow where supported, or place it on a filesystem that restricts symlink creation by non-owners via fs.protected_symlinks=1
Avoid running untrusted workloads under the swtpm account and isolate TPM-enabled guests to hosts with hardened service accounts

bash

# Enable kernel symlink and hardlink protections
sysctl -w fs.protected_symlinks=1
sysctl -w fs.protected_hardlinks=1

# Persist across reboots
echo 'fs.protected_symlinks=1' >> /etc/sysctl.d/99-symlink-hardening.conf
echo 'fs.protected_hardlinks=1' >> /etc/sysctl.d/99-symlink-hardening.conf

# Restrict swtpm log directory permissions
chown root:swtpm /var/log/swtpm/libvirt/qemu
chmod 0750 /var/log/swtpm/libvirt/qemu