GNU LibreDWG EUVD-2026-31788

The attacker must have local access and low-level OS privileges (PR:L per CVSS vector) on the system where dwggrep is installed. Exploitation specifically requires the dwggrep utility to be invoked against an attacker-controlled or attacker-supplied DWG file - the vulnerable code path is in the match_BLOCK_HEADER function of dwggrep.c, not in the core LibreDWG parsing library. Systems that use LibreDWG as a library but do not execute the dwggrep binary against untrusted input are not exposed. No network access is required (AV:L). No user interaction beyond standard local execution is needed (UI:N). Exploitation is not automatable per SSVC, meaning it cannot be reliably triggered at scale without specific local file placement.

Real-world risk is low. CVSS 4.0 scores this at 1.9 (Very Low), constrained by local-only attack vector (AV:L), low privileges required (PR:L), and availability-only impact (VA:L with VC:N/VI:N). EPSS at 0.01% (2nd percentile) independently confirms minimal exploitation probability. SSVC categorizes exploitation as 'poc' (not active), automatable as 'no' (requires local file execution), and technical impact as 'partial' (availability only). The vulnerability is not listed in CISA KEV. The primary concern is a crash of the dwggrep command-line utility - there is no code execution, privilege escalation, or data exposure pathway indicated. The sole elevated signal is the existence of public exploit code. One discrepancy worth flagging: the exploit artifact referenced is named 'heap_oob_write_read' while the CVE classifies the bug as CWE-476 (null pointer dereference) - if the true bug class is heap OOB write/read, the actual severity could be higher than currently assessed. Defenders should verify this against GitHub issue #1247.

A local user with standard account privileges places a crafted DWG file in a location processed by dwggrep - for example, in a shared directory monitored by an automated scan script. When dwggrep processes the file, match_BLOCK_HEADER dereferences a null pointer, causing the utility to crash and producing a denial of service for that process. A publicly available exploit artifact exists (referenced at the HackC0der CVE-Repos GitHub), though its naming as 'heap_oob_write_read' suggests the actual primitive may differ from the classified null pointer dereference.