libpff CVE-2026-110598

Requires the victim to open or process an attacker-crafted PST, OST, or PAB file using libpff (or its bindings pypff / the pffexport tool); the file must contain multi-value property entries of type PT_MV_STRING8, PT_MV_UNICODE, or PT_MV_BINARY whose stored offsets are non-monotonic (decreasing), which drives the integer underflow in libpff_record_entry_get_multi_value(). Per the CVSS vector this is a LOCAL vector (AV:L) with required passive user interaction (UI:P) and no authentication (PR:N), so exploitation is limited by the need to deliver a malicious file and have it parsed - it is not remote or zero-click. Realistic exposure is highest where untrusted PST/OST/PAB files are ingested automatically (DFIR, e-discovery, mail migration); the impact is bounded to a crash (DoS) plus disclosure of adjacent heap memory, not integrity compromise or code execution.

This is a moderate-severity, file-parsing memory-safety flaw whose real-world risk is bounded by its delivery model rather than its technical novelty. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:H) tells a consistent story: exploitation is LOCAL and requires passive user interaction (a victim must open or process an attacker-supplied file), so there is no network-facing, zero-click exposure. No EPSS score and no CISA KEV entry were provided, and there is no KEV or POC flag in the input, so under the precision rules this is treated as 'no public exploit identified at time of analysis' - although a detailed third-party technical writeup (hackmd) and the exact vulnerable source lines are publicly referenced, which materially lowers the effort to reproduce. The impact mix is telling and internally consistent: VA:H (reliable crash / denial of service of libpff, pypff, or pffexport) with only VC:L (disclosure of adjacent heap memory, not full read primitive) and VI:N (no integrity impact), matching CWE-125 (out-of-bounds read) rather than a code-execution write primitive. Net: this is a genuine but lower-priority issue for most organizations - a crash-and-leak bug in a forensics/mail-parsing library, not a mass-exploitable RCE. It becomes meaningfully more important for operators who auto-ingest untrusted PST/OST/PAB files (e-discovery, DFIR, mail-migration pipelines), where attacker-controlled input reaches the parser automatically.

An attacker crafts a malicious PST, OST, or PAB file whose multi-value property entries (PT_MV_STRING8, PT_MV_UNICODE, or PT_MV_BINARY) use decreasing, non-monotonic offsets, then delivers it to a victim (e.g., as a mailbox export submitted to a forensics or e-discovery pipeline). When the victim processes the file with libpff, pypff, or pffexport, the integer underflow in libpff_record_entry_get_multi_value() triggers a heap out-of-bounds read, crashing the tool and potentially leaking adjacent heap memory. No public exploit is flagged in the input, but a public technical writeup and the exact vulnerable code are referenced, lowering reproduction effort.