libdwarf CVE-2026-116732

Exploitation requires a libdwarf-based consumer (version ≤2.3.3) to parse an attacker-crafted object file whose .debug_addr section specifies a non-zero table starting offset, which dwarf_debug_addr_table() fails to include when validating the section unit length; dwarf_debug_addr_by_index() then reads beyond the heap buffer. Limiting factors: the attack vector is local (AV:L) and demands user interaction (UI:P) - a victim or automated pipeline must actually process the malicious file - and impact is bounded to small heap-memory disclosure and denial of service, with no code execution or integrity impact indicated. There is no remote network path and no privilege required on the attacker side, but the flaw is only reachable through the .debug_addr parsing code path.

This is a genuine but low-priority memory-safety defect, not an urgent emergency. The input CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VC:L/VI:N/VA:L) describes a local, low-complexity flaw that requires passive user interaction - a victim must run a libdwarf-based consumer against an attacker-supplied object file - and yields only limited confidentiality (adjacent heap-byte disclosure) and limited availability (consumer crash) impact, consistent with the 4.8 score. The EPSS score is very low (0.13%, 3rd percentile) and there is no CISA KEV listing, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the low-impact, local, UI-dependent profile. Reported by VulnCheck with a vendor patch available and a technical write-up published, so the mechanism is well understood. These signals are mutually consistent: moderate severity, low exploitation probability, no active exploitation - patch on a normal monthly cadence rather than treating it as a fire. One nuance: the root cause (omitting the table starting offset when validating .debug_addr unit length) is confirmed by the commit diff, which adds overflow checks and an exact end-offset equality check.

An attacker crafts a malicious object file whose .debug_addr section declares a non-zero table starting offset, then gets a victim to process it with a tool built on libdwarf (e.g., a debugger, symbolizer, or binary-analysis utility). When dwarf_debug_addr_table() validates the unit length without accounting for that starting offset, dwarf_debug_addr_by_index() reads past the heap buffer, leaking adjacent heap bytes to the consumer or crashing it. A public PoC reference exists (hackmd write-up and GitHub issue #336); it is not verified as working exploit code, and the local vector plus required user interaction make this opportunistic rather than mass-exploitable.