libslirp CVE-2026-9539: Quarkslab reports heartbleed-like TCP data leak

What happened

According to a Quarkslab blog post, CVE-2026-9539 is described as a “heartbleed-like” out-of-bound read in libslirp’s TCP code. Quarkslab says the bug can expose data from other connections. Quarkslab describes libslirp as a user-mode networking library used by virtual machines, containers and other tools, and says it is QEMU’s default network stack.

Quarkslab says the bug was found by Bruce Chen and Shi Weiming of STAR Labs SG Pte. Ltd and was reported to libslirp in May 2026. Quarkslab says its own fuzzer was running against this code around the same time but did not detect the bug because of a lack of detection. The post is mainly about Quarkslab’s fuzzing tooling. Quarkslab did not discover the vulnerability.

Quarkslab gives this technical summary (Quarkslab):

• libslirp allocates two large arrays (128KiB) for socket send and receive buffers and walks them as ring buffers.
• libslirp checked the TCP urgent pointer against the size of an intermediate buffer, not against the amount of valid data in the socket.
• This leads to an integer underflow in the sosendoob function, so even more data is read.
• The whole receive buffer is sent over multiple packets. This can include leftovers from a previous allocation if the memory chunk was freed and reused for the socket.
• The read stays inside the ring buffer area, so Address Sanitizer does not flag it. Quarkslab says UndefinedBehaviorSanitizer with integer overflow checks does detect the underflow.

The following are not confirmed in the available sources: affected and fixed libslirp versions, an official severity rating, and any downstream QEMU or distribution patch status. The NVD record was linked in the source data, but its content was not available. The severity on this page is set to info only because no source provides a rating.

Am I affected?

• You may be affected if you use libslirp, including through QEMU’s default user-mode networking, according to Quarkslab.
• The specific vulnerable version range is not confirmed in the sources.
• Quarkslab does not report in-the-wild exploitation.

What to do now

1. Find which systems run QEMU or other tools with libslirp user-mode networking.
2. Check the NVD entry for CVE-2026-9539 and libslirp’s own tracker for affected and fixed versions. Fixed versions are not confirmed in the sources.
3. Apply your distribution’s or vendor’s libslirp and QEMU updates once a fix is confirmed.
4. If you fuzz C code that uses internal allocators, Quarkslab suggests building with -fsanitize=unsigned-integer-overflow,signed-integer-overflow or manually poisoning custom allocator regions with ASAN, because plain ASAN missed this bug (Quarkslab).

Sources

• Quarkslab: Snapshotting our way to CVE-2026-9539
• NVD: CVE-2026-9539