libslirp CVE-2026-120830

Exploitation requires that the target host uses libslirp as its network backend - e.g. QEMU user-mode ('slirp') networking or rootless Podman's default slirp4netns/libslirp networking - and that the attacker controls a guest VM or container attached to that emulated network, matching the AV:A adjacent position. The attacker must be able to emit raw/malformed IPv4 traffic that causes libslirp to generate an ICMP error (the icmp_forward_error() path). No host authentication or user interaction is needed (PR:N/UI:N). Limiting factors: deployments that do NOT use libslirp networking (e.g. bridged/macvlan/kernel-based VM networking, or CNI-based pod networking that does not route through libslirp) are not exposed via this path; and because the bug is a heap over-read, the attacker cannot choose which host memory is leaked, only that some adjacent host memory is disclosed.

This is a moderate-severity information-disclosure flaw whose risk is driven almost entirely by the virtualization boundary it crosses rather than by any evidence of exploitation. The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N = 7.4) is internally consistent with the description: a guest or container (the 'adjacent' network position) can send a truncated/malformed packet with no host-side privileges or user interaction, and the scope change (S:C) reflects that leaked host-process memory crosses from the host's libslirp process into the guest/container. There is no KEV listing, no EPSS score, and no POC supplied in the input - the only third reference is the upstream libslirp FIX commit (21b33a6c) on freedesktop GitLab, not exploit code - so exploitation status is 'no public exploit identified at time of analysis.' The vuln.today decision label is 'this_week' (priority but not act_now/emergency), which aligns with a serious-but-not-actively-exploited info-leak: real priority for multi-tenant virtualization/container hosts, but not an emergency. One signal to note: impact is confined to confidentiality (C:H, I:N, A:N) and the leak is a heap over-read, so the data returned is unpredictable and not attacker-chosen - this is a memory-disclosure primitive, not code execution, which tempers the real-world severity relative to the 7.4 number.

An attacker who controls a guest VM or container that uses libslirp user-mode networking (for example QEMU user networking or rootless Podman's default slirp networking) sends a crafted, truncated IPv4 packet that triggers an ICMP error response. Because icmp_forward_error() trusts the IP header's total-length field without clamping it to the actual buffer size, libslirp over-reads adjacent host heap memory and copies it into the quoted-packet portion of the ICMP error returned to the guest, leaking host process memory across the virtualization boundary. No public exploit was identified at time of analysis, only the upstream fix commit.