There are packages installed that are affected by a vulnerability referenced in the following CVE:

  CVE-2026-63319


The version of qemu installed on the remote host is prior to 3.1.0-8. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2026-3866 advisory.

    In QEMU's VNC server implementation (ui/vnc.c), the set_pixel_format() function does not properly validate     the red_max, green_max, and blue_max fields from a client'sSetPixelFormat message. These fields are     received as 16-bit values but are stored internally as uint8_t. A malicious VNC client can send a max     value above 255 (e.g., 0x0100) whichpasses the existing non-zero validation check but silently truncates     to 0 upon assignment, leading to a division by zero in the Tight PNG palette encoding path. This allows a     remoteattacker to crash the QEMU process, resulting in a denial of service for all guests served by that     QEMU instance. Fixed in QEMU v11.0.3 and v10.0.12. (CVE-2026-15578)

    In QEMU's USB redirection (usbredir) implementation, a use-after-free vulnerability exists in the     usbredir_buffered_bulk_packet() function in hw/usb/redirect.c. When processing amulti-fragment buffered     bulk packet that is split into max-packet-size chunks, only the final fragment owns the shared parser     memory allocation (via free_on_destroy). If bufp_alloc()drops the final fragment due to queue overflow, it     frees the backing buffer while earlier fragments already queued still hold interior pointers into it.
    Subsequent guest bulk-INtransfers then read from freed heap memory. A malicious or compromised USB device     (or a crafted usbredir stream) could trigger this condition, potentially leading to informationdisclosure     from heap memory or a QEMU process crash (denial of service). This vulnerability has existed since QEMU     v1.4.0-rc0 and is fixed in v11.0.3 and v10.0.12. (CVE-2026-15705)

    Incorrect calculation of the boundary condition when tracking lossy rectangles in the worker thread will     result in an OOB write which can corrupt further worker state, and/or trigger any guard pages that may lie     beyond the VncWorker struct. This can be triggered through careful choice of the display resolution in the     guest OS by an unprivileged user. (CVE-2026-48002)

    Incorrect loop bounds in vnc_update_freq result in iterating past the last row and past the last column in     the VNC stats array. With suitably chosen dimensions this could be a OOB read that accesses memory beyond     the VncDisplay struct that the stats array is embedded in.

    Should this hit a guard page, it could trigger a guest crash. If it does not, then the VNC frequency stats     will be updated with garbage. (CVE-2026-48003)

    In QEMU's VNC server implementation (ui/vnc.c), the vnc_refresh_lossy_rect() function contains an out-of-     bounds write vulnerability when marking dirty bitmap rows during lossy tilerefresh. The function     unconditionally marks a full VNC_STAT_RECT (64) rows of the dirty bitmap for each tile. When the display     height is not a multiple of 64 pixels, the last tilerow is a partial tile and the loop writes past the end     of the vs->dirty[VNC_MAX_HEIGHT] array. For example, with a 2160-pixel-high display, the last stat tile     starts at y=2112 andthe 64-row loop writes rows 2112-2175, overflowing 16 rows (640 bytes) past the dirty     bitmap into subsequent VncState fields. This heap buffer overflow could potentially be exploitedby a     malicious VNC client that negotiates a specific display resolution to corrupt QEMU process memory, leading     to denial of service or possibly arbitrary code execution. Fixed inQEMU v11.0.3 and v10.0.12.
    (CVE-2026-61475)

    In QEMU's USB redirection (usbredir) implementation (hw/usb/redirect.c), a malicious usbredir peer can     send an ep_info message that resets max_packet_size to 0 after bulk receivinghas already started. This     leads to multiple exploitable conditions: (1) an infinite loop in usbredir_buffered_bulk_packet() where     the splitting loop increments by max_packet_size (0) and never progresses, (2) a SIGFPE (floating point     exception) in usbredir_buffered_bulk_in_complete_ftdi() from a modulo-by-zero operation, and (3) a SIGFPE     in usbredir_handle_buffered_bulk_in_data() from a division-by-zero when computing bytes_per_transfer. A     malicious USB redirection peer can exploit this to crash the QEMU process (denial of service) orcause it     to hang indefinitely. Fixed in QEMU v11.0.3 and v10.0.12. (CVE-2026-63319)

    In QEMU's 9pfs (virtio-9p) implementation, the TXATTRCREATE and TXATTRWALK request handlers do not limit     the number of simultaneously open xattr FIDs. Each xattr FID allocates ahost memory buffer for the     extended attribute value. A malicious privileged guest user with direct 9p server access can exploit this     by repeatedly creating xattr FIDs without closingthem, leading to unbounded host memory consumption and     eventual host memory exhaustion (denial of service). This vulnerability has existed since QEMU v0.14.0-rc0     and is fixed inv11.0.3 and v10.0.12. (CVE-2026-8348)

    An out-of-bounds heap read and integer underflow in the TCP urgent data handling (sosendoob) in     freedesktop.org libslirp version before v4.9.2 on hypervisor host environments (e.g., QEMU) allows a     privileged guest VM attacker (root or CAP_NET_RAW) to leak gigabytes of sensitive host-process heap memory     via sending crafted TCP segments with manipulated URG flags and urgent pointers (ti_urp). (CVE-2026-9539)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In QEMU's VNC server implementation (ui/vnc.c), the set_pixel_format() function does not properly validate     the red_max, green_max, and blue_max fields from a client'sSetPixelFormat message. These fields are     received as 16-bit values but are stored internally as uint8_t. A malicious VNC client can send a max     value above 255 (e.g., 0x0100) whichpasses the existing non-zero validation check but silently truncates     to 0 upon assignment, leading to a division by zero in the Tight PNG palette encoding path. This allows a     remoteattacker to crash the QEMU process, resulting in a denial of service for all guests served by that     QEMU instance. Fixed in QEMU v11.0.3 and v10.0.12. (CVE-2026-15578)  In QEMU's USB redirection (usbredir)     implementation, a use-after-free vulnerability exists in the usbredir_buffered_bulk_packet() function in     hw/usb/redirect.c. When processing amulti-fragment buffered bulk packet that is split into max-packet-size     chunks, only the final fragment owns the shared parser memory allocation (via free_on_destroy). If     bufp_alloc()drops the final fragment due to queue overflow, it frees the backing buffer while earlier     fragments already queued still hold interior pointers into it. Subsequent guest bulk-INtransfers then read     from freed heap memory. A malicious or compromised USB device (or a crafted usbredir stream) could trigger     this condition, potentially leading to informationdisclosure from heap memory or a QEMU process crash     (denial of service). This vulnerability has existed since QEMU v1.4.0-rc0 and is fixed in v11.0.3 and     v10.0.12. (CVE-2026-15705)  Incorrect calculation of the boundary condition when tracking lossy rectangles     in the worker thread will result in an OOB write which can corrupt further worker state, and/or trigger     any guard pages that may lie beyond the VncWorker struct. This can be triggered through careful choice of     the display resolution in the guest OS by an unprivileged user. (CVE-2026-48002)  Incorrect loop bounds in     vnc_update_freq result in iterating past the last row and past the last column in the VNC stats array.
    With suitably chosen dimensions this could be a OOB read that accesses memory beyond the VncDisplay struct     that the stats array is embedded in.  Should this hit a guard page, it could trigger a guest crash. If it     does not, then the VNC frequency stats will be updated with garbage. (CVE-2026-48003)  In QEMU's VNC     server implementation (ui/vnc.c), the vnc_refresh_lossy_rect() function contains an out-of-bounds write     vulnerability when marking dirty bitmap rows during lossy tilerefresh. The function unconditionally marks     a full VNC_STAT_RECT (64) rows of the dirty bitmap for each tile. When the display height is not a     multiple of 64 pixels, the last tilerow is a partial tile and the loop writes past the end of the     vs->dirty[VNC_MAX_HEIGHT] array. For example, with a 2160-pixel-high display, the last stat tile starts at     y=2112 andthe 64-row loop writes rows 2112-2175, overflowing 16 rows (640 bytes) past the dirty bitmap     into subsequent VncState fields. This heap buffer overflow could potentially be exploitedby a malicious     VNC client that negotiates a specific display resolution to corrupt QEMU process memory, leading to denial     of service or possibly arbitrary code execution. Fixed inQEMU v11.0.3 and v10.0.12. (CVE-2026-61475)  In     QEMU's USB redirection (usbredir) implementation (hw/usb/redirect.c), a malicious usbredir peer can send     an ep_info message that resets max_packet_size to 0 after bulk receivinghas already started. This leads to     multiple exploitable conditions: (1) an infinite loop in usbredir_buffered_bulk_packet() where the     splitting loop increments by max_packet_size (0) and never progresses, (2) a SIGFPE (floating point     exception) in usbredir_buffered_bulk_in_complete_ftdi() from a modulo-by-zero operation, and (3) a SIGFPE     in usbredir_handle_buffered_bulk_in_data() from a division-by-zero when computing bytes_per_transfer. A     malicious USB redirection peer can exploit this to crash the QEMU process (denial of service) orcause it     to hang indefinitely. Fixed in QEMU v11.0.3 and v10.0.12. (CVE-2026-63319)  In QEMU's 9pfs (virtio-9p)     implementation, the TXATTRCREATE and TXATTRWALK request handlers do not limit the number of simultaneously     open xattr FIDs. Each xattr FID allocates ahost memory buffer for the extended attribute value. A     malicious privileged guest user with direct 9p server access can exploit this by repeatedly creating xattr     FIDs without closingthem, leading to unbounded host memory consumption and eventual host memory exhaustion     (denial of service). This vulnerability has existed since QEMU v0.14.0-rc0 and is fixed inv11.0.3 and     v10.0.12. (CVE-2026-8348)  An out-of-bounds heap read and integer underflow in the TCP urgent data     handling (sosendoob) in freedesktop.org libslirp version before v4.9.2 on hypervisor host environments     (e.g., QEMU) allows a privileged guest VM attacker (root or CAP_NET_RAW) to leak gigabytes of sensitive     host-process heap memory via sending crafted TCP segments with manipulated URG flags and urgent pointers     (ti_urp). (CVE-2026-9539) (CVE-2026-63319)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
463470	Echo: qemu: security update to 1:10.0.12+ds-0+deb13u1	Tenable Cloud Security	Echo Local Security Checks	10/2/2026	10/2/2026	medium
463470	Echo: qemu: security update to 1:10.0.12+ds-0+deb13u1	Tenable Self-Hosted Container Security	Echo Local Security Checks	10/2/2026	10/2/2026	medium
337242	Amazon Linux 2 : qemu, --advisory ALAS2-2026-3866 (ALAS-2026-3866)	Nessus	Amazon Linux Local Security Checks	8/18/2026	8/18/2026	medium
330021	Linux Distros Unpatched Vulnerability : CVE-2026-63319	Nessus	Misc.	7/26/2026	9/26/2026	high

Detections

Analytics

Plugins Search

medium

medium

medium

high