CVE-2025-13193: Libvirt Snapshots Create World Readable Files

A flaw in libvirt causes external inactive snapshots created for shut-down virtual machines to be written with world-readable permissions, allowing any local, unprivileged user on the host to read guest disk contents and resulting in a medium-severity information disclosure vulnerability tracked as CVE-2025-13193.

Background / Overview​

Libvirt is the widely used virtualization management layer that talks to QEMU/KVM, Xen and other hypervisors and supplies utilities such as virsh and the libvirtd daemon to create, manage and snapshot virtual machines. Snapshots are a core feature: they let administrators capture a VM’s disk and (optionally) memory state so they can roll back, test upgrades, or preserve a point-in-time image. External snapshots in particular create new image files (for example, qcow2 files) and instruct QEMU to use the new file as the live disk while keeping the prior data in the snapshot file. CVE-2025-13193 arises from the way libvirt invokes the external snapshot workflow: a helper (qemu-img) creates the new snapshot file but, historically, libvirt did not explicitly control the process umask used for that qemu-img invocation. That omission meant the created snapshot file could inherit a permissive mode (commonly 0644), making the snapshot world-readable. An attacker with low-privilege local access to the host — or in multi-tenant environments, another tenant that shares the same host — can therefore open the snapshot file and inspect the guest’s disk content, including configuration files, credentials or other sensitive data. This is an information-disclosure vulnerability classed as Incorrect Default Permissions / CWE-276.

---

What exactly went wrong (technical root cause)​

At a technical level, the snapshot creation path executes qemu-img to make a new external snapshot file. qemu-img creates the file using the process umask in effect when it runs; libvirt previously launched this subprocess without setting a restrictive umask, so the new file could be created with the host’s default permissive mask. In practice, that commonly resulted in files with read permission for owner and group and for others (world-readable). The defect is not a memory-corruption bug or a malformed-image parser — it’s a permissions/operation mistake that makes sensitive data accessible to any local account that can read regular files on the host filesystem. Upstream maintainers proposed and merged a small but targeted fix: set the subprocess umask to be restrictive (for example 0066 or 0077) before invoking qemu-img, so newly created snapshot files are only readable by the owning libvirt/QEMU user. The patch was authored and discussed publicly on libvirt development lists and accepted into the project tree. Distribution maintainers then incorporated the fix into vendor packages and issued advisories.

---

How it can be exploited — attacker prerequisites and scope​

This vulnerability’s exploit model is straightforward and constrained:

• Attack vector: Local. The attacker must have access to the host filesystem as a non-privileged local user, or be able to execute code on the host (for example via a compromised container or unprivileged shell account on shared infrastructure).
• Privileges required: Low. No root privileges are needed; the flaw leverages world-readable permissions on files that should have been owner-only.
• User interaction: None. An attacker who already has local access can read the snapshot file once it exists.
• Likelihood in different environments: High for multi-tenant hosts, developer/test machines, CI runners and public clouds that allow unprivileged user accounts or containers to write to the same host; lower for tightly controlled single-tenant production hosts where local users are restricted. Practical risk is therefore strongly environment-dependent.

Because the vulnerability is a confidentiality leak (guest disk contents), its impact can be significant even though it doesn’t permit remote code execution on the host. Exfiltrated data could include plaintext credentials, SSH keys, configuration files, or other secrets that enable lateral movement or further escalation. Several distribution trackers and CNAs therefore assign a moderate CVSS (v3.1) base score — commonly reported around 5.5 — reflecting low attack complexity but high confidentiality impact.

---

Affected software and where to patch​

The issue was assigned CVE-2025-13193 and has been acknowledged in vendor and distribution trackers. Major points to note:

• The NVD entry summarizes the issue and shows the record is awaiting enrichment; the NVD description matches the root cause: external inactive snapshots created as world-readable.
• Distribution advisories and trackers (Debian, SUSE, Red Hat and others) list affected packages, map fixed package versions, and point to the upstream fix or commit. Debian’s tracker references the exact commit that introduced the vulnerable behavior and the commit that fixes it; Debian stable/bookworm and older releases may be unaffected if the vulnerable code was introduced later, while unstable/testing branches may be vulnerable until the package is updated.
• SUSE and other vendors published security updates that explicitly mention CVE-2025-13193 and list patched libvirt packages; SUSE’s advisory shows the fix included in their libvirt update.

Administrators should consult their distribution’s security advisory for precise package names and fixed versions, test the update in staging, and apply to production as soon as practicable.

---

Practical impact scenarios (real-world consequences)​

• Shared development servers and CI/CD runners: These systems often run untrusted builds or test VMs and may host multiple tenants. If an attacker can run a job that results in a snapshot, or can simply read the snapshot files after they’re created, secrets embedded in VM images (API keys, tokens, credentials) become exposed.
• Cloud and VPS hosts used by different customers: Even if customers have isolated VMs, shared host filesystem artifacts may be readable by local accounts in certain setups. An exposed snapshot could leak a guest’s disk content to another customer on the same host.
• Forensic and incident response scenarios: Incident responders and attackers both often collect snapshots. Without strict permissions, a poorly protected snapshot created for troubleshooting could be copied off-host and analyzed elsewhere by unauthorized users.
• Supply-chain and CI pipelines: Build or test VM images that include pre-populated credentials or environment-specific secrets are particularly sensitive; world-readable snapshots dramatically increase the blast radius if those images are saved in external snapshot files.

---

Detection, hunting, and immediate checks​

Because this is a file-permission problem, detection focuses on identifying world-readable snapshot files and monitoring snapshot creation events.
High-value checks and commands (examples):

• Find snapshot files with world-readable permissions in typical libvirt storage directories:
• find /var/lib/libvirt/images -type f -perm /o=r -ls
• find /var/lib/libvirt -name '[I]snap[/I]' -type f -perm /o=r -ls
  These commands list files that grant read (r) to others (the world). Adjust paths for your distro’s libvirt image storage. (Operators should run these commands as root or with appropriate privileges.
• Audit recent snapshot creation times and file owners:
• stat /var/lib/libvirt/images/<snapshot-file> to check owner, group and mode.
• Monitor logs for snapshot operations:
• Check libvirtd logs (journalctl -u libvirtd or /var/log/libvirt/) for snapshot create messages and correlate timestamps with unexpectedly permissioned files.
• Kubernetes/KubeVirt cross-checks: Platforms that mix containers and VMs (for example, KubeVirt) should also hunt for unexpected writable volumes or symlink tricks; cross-layer vulnerabilities make detection more complex (see multilayer examples and threat model analysis).

Operators should treat any discovered world-readable snapshot files as potentially exposed secrets. If you find such files, preserve them for investigation but assume the contained secrets (keys, passwords, tokens) are compromised and rotate them accordingly.

---

Immediate mitigations and recommended patching steps​

• Patch promptly: Apply fixed libvirt packages from your distribution vendor. For example, SUSE, Debian and Red Hat have tracked the issue and published updates — verify and deploy the vendor-supplied packages in staging before production rollout.
• Confirm the upstream fix: The upstream libvirt fix sets a restrictive umask for the qemu-img invocation that produces external snapshot files (e.g., umask 0066 or stricter). Ensure your patched libvirt includes the commit or release containing that change. The upstream patch was discussed on libvirt developer lists and merged into the codebase.
• Harden file access until patched: If an immediate patch is not possible:
• Restrict local filesystem access: ensure that only trusted accounts have read access to libvirt image directories (/var/lib/libvirt/images and any custom storage paths). Use stricter POSIX ACLs or SELinux/AppArmor enforcement to limit access.
• Enforce host-level separation: do not allow untrusted users (or container workloads) to run on VM hosts or to access host image directories.
• For CI/services that must create snapshots, restrict who can schedule those jobs and run them in isolated, single-tenant hosts.
• Configuration hardening: After patching, verify the behavior:
• Create a controlled external snapshot in a test VM and confirm the snapshot file permissions are owner-only (no world-readable bit).
• Check that new snapshot files are created with restrictive modes by default.
• Rotate exposed secrets: If you discover previously world-readable snapshots, treat contained secrets as compromised: rotate SSH keys, tokens, passwords, and any other secrets discovered in the images. Follow incident-response best practices for containment and remediation.

---

Longer-term operational recommendations​

• Treat VM snapshots and image artifacts as high-value data. Apply the same least-privilege and secret-management controls to images that you apply to source code, artifacts and container images.
• Enforce immutable, operator-managed storage for production VMs where possible: prefer storage that does not permit tenant-writable content in control-plane or image directories.
• Add admission controls or CI gating for image artifacts in shared systems (for example, block arbitrary snapshot creation on shared runners).
• Maintain robust host hardening: configure SELinux/AppArmor policies, limit sudo access, remove unnecessary local accounts, and enable HIDS/EPP that can detect anomalous file creations and permission changes.
• Include libvirt and virtualization toolchains in routine vulnerability scanning and patching cycles; this class of bug has operational impact disproportionate to its code size.

These practices reflect a broader lesson: virtualization subsystems connect multiple layers (guest disk images, host filesystems, management daemons), and small lapses in file-permission hygiene can create outsized confidentiality risk. Several recent virtualization-related advisories (including KubeVirt symlink attacks and other libvirt/QEMU hardening work) show the same cross-layer pattern and why operators must treat storage and mount semantics as part of their threat model.

---

Why Windows administrators and mixed-environment operators should care​

Even though libvirt and QEMU are primarily Linux-hosted technologies, Windows environments commonly interact with them in enterprise and cloud contexts:

• Windows teams often rely on mixed infrastructure (Hyper-V on some hosts, KVM/QEMU on others, and Kubernetes with KubeVirt in dev/test). A leaked Linux VM snapshot can contain Windows credentials, Active Directory service account material, or configuration used to access Windows resources.
• Backup servers, artifact repositories and CI systems that are Windows-based may consume VM images or store snapshots; any leak in the upstream virtualization host can cascade into those Windows systems via credential theft or configuration disclosure.
• Security teams that centralize incident response across Windows and Linux estates must include virtualization image hygiene in their playbooks and asset inventories. Several advisories from other virtualization incidents emphasize rotating credentials and validating integrity of backups and images after any information disclosure.

---

Verification and cross-checks (what was confirmed and what remains uncertain)​

Verified and corroborated facts:

• Public vulnerability trackers and vendor advisories describe CVE-2025-13193 as an information disclosure caused by world-readable external inactive snapshots. Multiple independent trackers (NVD, Debian, SUSE, OpenCVE) reflect the same description and similar severity.
• Upstream libvirt developers proposed and merged a fix that sets a restrictive umask for the qemu-img subprocess invoked during snapshot creation; distribution packages incorporate this fix as part of security updates.
• The practical exploit requires local access to the host; remote unauthenticated exploitation is not described. The attack is real and straightforward in environments that allow unprivileged local access to snapshot files.

Unverified or environment-specific details:

• Claims of widespread in-the-wild exploitation have not been substantiated at the time of the advisories; absence of public exploit reports does not imply no risk. Operators should assume that once the vulnerability is disclosed, PoCs may appear quickly.
• The exact list of affected package versions varies by distribution and by when the vulnerable code was introduced into a distro’s package; administrators must consult their vendor advisory to determine exposure for their specific release. Debian’s tracker explicitly notes the vulnerable commit introduction point for different releases; cross-check your distro’s package changelog before taking action.

---

Checklist: fast operational playbook​

• Inventory: identify hypervisor hosts and libvirt instances (ps -ef | grep libvirtd, rpm -qa | grep libvirt, dpkg -l | grep libvirt).
• Detect: run find to locate any world-readable snapshots in configured storage paths.
• Patch: apply vendor-provided libvirt updates (verify package versions and that the patch contains the umask fix).
• Harden: restrict access to libvirt image paths via ACLs/SELinux/AppArmor and disallow untrusted user accounts on VM hosts.
• Rotate: assume secrets found in exposed snapshots may be compromised; rotate keys and tokens as needed.
• Validate: create a controlled snapshot in a test environment and confirm new files are owner-only readable.
• Monitor: enable alerting for snapshot creation events, unexpected file permission changes and local file reads of snapshot artifacts.

---

Conclusion​

CVE-2025-13193 is a classic example of how a small operational oversight — not setting a restrictive umask for a subprocess — can produce a significant confidentiality problem across infrastructure. The bug’s exploit path is not exotic: a world-readable external snapshot permits any local user who can access the host filesystem to read entire guest images and harvest secrets. The remediation is straightforward and already available from upstream and major distributors: patch libvirt so it sets a restrictive umask for qemu-img and ensure your distribution’s security update is applied.
However, the operational lesson goes deeper: virtualization introduces cross-layer risks that must be managed with consistent policy, least privilege, and defensive controls. Administrators should patch promptly, hunt for exposed snapshot files, rotate any exposed secrets, and tighten host-level access controls — especially on multi-tenant systems, CI runners and developer hosts. Failure to treat image artifacts as sensitive data invites the same kind of reconnaissance and escalation paths that past virtualization incidents have repeatedly demonstrated.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center