CVE-2026-9539: libslirp Information Disclosure Vulnerability

CVE-2026-9539 Overview

CVE-2026-9539 is an out-of-bounds heap read combined with an integer underflow in the TCP urgent data handling routine (sosendoob) of libslirp, the user-mode network stack used by QEMU and other hypervisors. Versions before v4.9.2 are affected. A privileged guest VM attacker with root or CAP_NET_RAW can craft TCP segments with manipulated URG flags and urgent pointers (ti_urp) to read host-process heap memory. The flaw enables cross-boundary information disclosure from guest to hypervisor host process, leaking potentially gigabytes of sensitive memory. The weakness is classified as [CWE-125] Out-of-Bounds Read.

Critical Impact
A privileged guest can exfiltrate large volumes of host hypervisor heap memory across the VM boundary, breaking the guest-host confidentiality boundary.

Affected Products

freedesktop.org libslirp versions prior to v4.9.2
QEMU and other hypervisors that embed libslirp for user-mode networking
Guest VM environments using SLIRP-based networking on vulnerable hosts

Discovery Timeline

2026-06-24 - CVE-2026-9539 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-9539

Vulnerability Analysis

The defect resides in sosendoob, the function in libslirp responsible for forwarding TCP urgent (out-of-band) data from the guest to the host-side socket. The routine derives a length value from the urgent pointer field (ti_urp) supplied by the guest. When an attacker manipulates the URG flag and the urgent pointer in crafted TCP segments, the computed length wraps around due to an integer underflow. The underflowed value is then used as a size parameter when reading from an internal heap buffer, producing an out-of-bounds read far beyond the intended bounds. Because libslirp runs inside the hypervisor's host process, the leaked bytes belong to the host process heap rather than the guest. Repeated requests allow an attacker to siphon contiguous and adjacent regions, with the advisory noting disclosure on the order of gigabytes.

Root Cause

The root cause is missing validation of guest-supplied TCP urgent pointer values before they participate in arithmetic that produces a buffer length. The unsigned subtraction underflows when the urgent pointer is outside expected ranges, yielding an enormous length and bypassing the implicit bounds expected by downstream copy and read operations.

Attack Vector

Exploitation requires local access from within a guest VM with elevated network privileges (root or CAP_NET_RAW). The attacker constructs raw TCP segments with the URG flag set and a crafted ti_urp value, then triggers the sosendoob path through normal SLIRP-routed networking. No host user interaction is needed. The scope is changed because the vulnerability crosses the guest-host trust boundary, but impact is limited to confidentiality of host memory; integrity and availability are not affected. No public proof-of-concept or in-the-wild exploitation has been reported.

Technical details and the upstream fix are described in the libslirp commit 927bca73 and the libslirp v4.9.2 release notes.

Detection Methods for CVE-2026-9539

Indicators of Compromise

Guest-originated TCP segments with the URG flag set and abnormal ti_urp values inconsistent with the segment payload length.
High volume of out-of-band TCP traffic from a single guest VM toward varied external destinations through the SLIRP interface.
Hypervisor host process memory growth or unusual read patterns concurrent with guest TCP urgent-data activity.

Detection Strategies

Inspect SLIRP-routed traffic for TCP segments where the urgent pointer exceeds the segment data length, a malformed condition characteristic of exploitation attempts.
Audit guest VMs for processes opening raw sockets or holding CAP_NET_RAW, narrowing the population capable of triggering the flaw.
Correlate hypervisor crash dumps or anomalous outbound payloads with guest TCP urgent-mode usage timelines.

Monitoring Recommendations

Enable logging on hypervisors for SLIRP network events and review for repeated URG-flagged segments from the same guest.
Track installed libslirp versions across the hypervisor fleet and alert on hosts still below v4.9.2.
Monitor outbound flow records from guest interfaces for sustained, low-rate TCP urgent traffic that could indicate slow memory exfiltration.

How to Mitigate CVE-2026-9539

Immediate Actions Required

Upgrade libslirp to v4.9.2 or later on every hypervisor host that uses SLIRP user-mode networking.
Rebuild or update QEMU and other dependent hypervisor packages against the patched libslirp, then restart affected VMs to load the fixed library.
Restrict guest VM administrative access and limit which workloads run with root or CAP_NET_RAW inside guests.

Patch Information

The upstream fix is included in libslirpv4.9.2. The corrective change is committed as 927bca7344e31fd58e2f7afaca784aad4400eb84 and validates urgent pointer values before they participate in length calculations within sosendoob. Refer to the GitLab work item #93 for the upstream tracking record.

Workarounds

Switch guest networking from SLIRP user-mode networking to alternative backends such as bridged or tap-based networking, which do not route through libslirp.
Where SLIRP must remain, remove CAP_NET_RAW from guest workloads and disallow raw socket usage to reduce the attack surface.
Isolate untrusted guest tenants on dedicated hosts until the patched libslirp is deployed across the fleet.

bash

# Verify the installed libslirp version on the hypervisor host
# (Replace the package manager command for your distribution)
rpm -q libslirp        # RHEL / Fedora
dpkg -s libslirp0      # Debian / Ubuntu

# After upgrading, confirm v4.9.2 or later is loaded by running QEMU processes
for pid in $(pgrep qemu); do
  echo "PID $pid:"
  ls -l /proc/$pid/map_files/ 2>/dev/null | grep -i slirp
done