libmspack EUVD-2026-113939

The consuming application must decompress an attacker-supplied MS-ZIP CAB file using libmspack's MS-ZIP decompressor path (cabd->extract()), and the crafted CAB's first block must begin with a back-reference so that the unchecked back-reference distance copies uninitialized window/heap memory into output. Affected: libmspack through 0.11alpha. The CVSS vector reports no authentication (PR:N) and no user interaction (UI:N). The key limiting factor is exfiltration: the attacker only gains value if the extracted output containing the stale heap bytes is returned to or observable by them, which depends on how the host application exposes extracted content - this deployment dependency aligns with the AT:P attack-requirement metric. The leaked data is uncontrolled stale heap (up to 32 KiB), not attacker-chosen memory.

This is a medium-severity information-disclosure issue (CVSS 4.0 base 6.3, VulnCheck). The 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a remotely deliverable, unauthenticated flaw, but impact is confined to confidentiality (VC:L; VI:N/VA:N) - it leaks up to 32 KiB of stale heap, not code execution or integrity loss. The AT:P metric signals an attack requirement is present; the description grounds this in a specific crafted-input condition (first MS-ZIP block must begin with a back-reference) rather than any attacker-uncontrolled race or timing, which the sources do not describe. No EPSS score and no CISA KEV entry are provided, and the vuln.today decision label is 'this_month' - a moderate, scheduled priority rather than act_now/emergency. A public PoC reference exists (a hackmd write-up and GitHub issue) but it is not verified as working exploit code, so this should not be conflated with active exploitation. Net: a real but moderate issue - the disclosed data is uncontrolled/stale heap and only useful to an attacker who can observe the extracted output, which tempers real-world risk below what a 'network/unauthenticated' reading alone would suggest. Missing signals: EPSS probability absent, and no fixed version is stated in the available data.

An attacker crafts a malicious MS-ZIP CAB file whose first block begins with a back-reference and submits it to an application that uses libmspack to extract it (for example an antivirus scanner, archive tool, or file-conversion service). During decompression cabd->extract() emits up to 32 KiB of uninitialized heap memory into the extracted output, and if the attacker can retrieve or observe that output they obtain potentially sensitive heap contents. A public PoC reference exists; it is not verified as working exploit code.