There's a heap overflow in qemu SLIRP which affects libguestfs, potentially allowing a malicious filesystem to take control of the confining qemu process and from there attack the host. It will affect libguestfs specifically when these two conditions are both met: - You're using the ‘direct’ backend. - Networking is enabled. The direct backend is the default upstream, but not in Fedora/RHEL/CentOS. It might also have been selected if you set the LIBGUESTFS_BACKEND=direct environment variable or called ‘guestfs_set_backend (g, "direct")’. Networking is enabled automatically by some tools (eg. virt-builder), or is enabled if your code called ‘guestfs_set_network (g, 1)’ (which is not the default). Note that the libvirt backend is _not_ affected, for two reasons: (1) It doesn't use SLIRP for networking (2) libvirt will use SELinux to confine the qemu process, so even if the appliance gains full control over qemu it is limited in what it can do. The solution in any case is to upgrade to a qemu containing the fix. Here's the upstream qemu patch: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/