CVE-2026-9539: libslirp TCP Urgent Data Memory Leak in QEMU and Hypervisors

Technical summary

The vulnerability exists in the sosendoob (send out-of-band) function of libslirp before version 4.9.2. TCP urgent data is processed through the URG flag and urgent pointer (ti_urp) field; however, the implementation does not properly validate these values before performing heap memory reads. An integer underflow can occur when calculating buffer offsets, leading to an out-of-bounds read condition. A malicious guest with raw socket capabilities can systematically send crafted TCP segments to trigger this flaw, reading from arbitrary host process heap locations. The vulnerability is classified under CWE-125 (Out-of-bounds Read), as it permits reading memory outside intended boundaries without bounds checking.

Business impact

Organizations running QEMU or other hypervisors using libslirp face a cross-VM memory disclosure risk. Compromised guest VMs—whether through supply-chain attack, insider threat, or container escape—gain a direct channel to exfiltrate host memory. This is particularly critical in multi-tenant cloud environments, serverless platforms, and edge computing deployments where host memory may contain secrets for other tenants or critical infrastructure services. The ability to leak gigabytes of data vastly exceeds typical side-channel attacks and could expose entire credential sets, API keys, or database connection strings. Compliance frameworks (PCI-DSS, HIPAA, SOC 2) requiring strong isolation between workloads are directly impacted.

Affected systems

libslirp versions prior to 4.9.2 are affected. libslirp is primarily integrated into QEMU for user-mode networking, but may also be embedded in other hypervisors, emulators, and container runtimes. The vulnerability requires a privileged guest user (root or CAP_NET_RAW) to exploit, limiting attack surface within restrictive containerized environments but remaining a serious threat in traditional VM scenarios where tenants have administrative access to their guest OS. Systems relying on libslirp for guest-to-host network emulation are vulnerable; direct network-attached systems are not impacted.

Exploitability

Exploitation requires local privilege within a guest VM (root or CAP_NET_RAW capability) and does not require user interaction. The attack is reliable and repeatable—an attacker can systematically craft TCP packets to read arbitrary regions of host memory. The barrier to exploitation is relatively low for any attacker who has already gained elevated access within a guest, making post-compromise lateral movement to the host highly feasible. No network-level attack vector exists; the threat is strictly from guest-to-host. CVSS 3.1 score of 6.5 (MEDIUM) reflects the local attack vector and privilege requirement, but understates the confidentiality impact in multi-tenant scenarios.

Remediation

Update libslirp to version 4.9.2 or later. Vendors and maintainers distributing QEMU, KVM, or other libslirp-dependent systems should issue updates immediately. For users unable to patch immediately, network isolation policies restricting guest TCP traffic may reduce exposure, though this is not a substitute for patching. Disable raw socket capabilities (CAP_NET_RAW) in guest containers if permitted by application requirements.

Patch guidance

Verify that libslirp has been upgraded to at least version 4.9.2 by checking package versions in your hypervisor distribution. For QEMU: consult your QEMU release notes and security advisories to confirm libslirp inclusion in the patched release. Container-based environments should ensure base images and runtimes are rebuilt with the patched libslirp. Test patched hypervisors in non-production environments first to confirm guest networking stability. Coordinate updates across all hypervisor hosts, as guest VM snapshots or migration may occur during patching windows.

Detection guidance

Detection of exploitation in-flight is challenging but focus monitoring on: (1) host kernel logs for unexpected memory access patterns or page faults from hypervisor processes; (2) guest-to-host TCP traffic anomalies, particularly rapid sequences of TCP segments with manipulated URG flags; (3) host process memory dumps or core files that may indicate data exfiltration. Post-incident forensics should examine guest VM network traffic captures and host memory images. No YARA or IDS signatures can reliably catch this attack without hypervisor-level packet inspection. Assume breach if a guest VM with CAP_NET_RAW access has been running for an extended period; conduct host memory analysis and credential rotation.

Why prioritize this

This vulnerability should be prioritized for immediate patching in any environment where guest VMs have privileged user access or where multi-tenancy concerns exist. The ability to leak gigabytes of host memory represents a severe confidentiality breach with direct implications for regulatory compliance and data protection. Although the CVSS score is MEDIUM, the practical impact in cloud and hypervisor deployments is HIGH. Organizations running QEMU on Linux, KVM-based platforms, or container runtimes with networking should treat this as critical-priority. Non-urgent for air-gapped, single-tenant, or trusted-guest environments.

Risk score, explained

CVSS 3.1 score of 6.5 (MEDIUM) is driven by: Attack Vector Local (AV:L, -2.5 points), Attack Complexity Low (AC:L, no penalty), Privileges Required (PR:L, -1.5 points), No User Interaction (UI:N, no penalty), Scope Changed (S:C, +1 point), Confidentiality High (C:H, +3 points), Integrity None (I:N, no impact), Availability None (A:N, no impact). The score correctly reflects the local privilege requirement and absence of integrity or availability impact; however, in multi-tenant and high-security-posture environments, the true risk may exceed this baseline due to the breadth and sensitivity of exposed data.

Frequently asked questions