pybddisasm CVE-2026-118446

Exploitation requires a consuming application to retain a Python reference to an element of an INSTRUX array member (for example an ND_OPERAND from the operands list, or another array-valued INSTRUX member) and then access that element after the parent INSTRUX object has been freed, because retaining the child element does not keep the parent allocation alive. It is a local, same-process condition (AV:L, PR:L) with no network vector and no attacker-supplied user interaction; it is bounded by the application's own object-lifetime behavior rather than by external input. Whether the outcome is a crash or disclosure of process memory depends on whether the freed allocation has been reused, and the memory-disclosure path is limited (VC:L).

This is a medium-severity, low-urgency issue rather than a top priority. The authoritative signal is the CVSS 4.0 vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H...), scored 6.9: the vector is local (AV:L), not network, and requires privileges/application context (PR:L), with impact dominated by availability (VA:H, process crash) and only limited confidentiality (VC:L, possible freed-memory exposure) and no integrity impact (VI:N). The vuln.today decision label is 'this_month' - meaningful but not act_now or emergency. No EPSS score, KEV listing, or PoC reference was provided, so there is no evidence of active exploitation or public exploit code. The strongest limiting factor beyond CVSS is structural: exploitation is not attacker-driven over a network but depends on the consuming application itself retaining and then using a stale array element after the parent INSTRUX object is freed - a self-inflicted use-after-free. Combined with the fact that pybddisasm is no longer maintained and niche, this reads as a genuine but low-real-world-risk memory-safety defect, not a widespread exploitable threat. No signals conflict here; the main gap is the absence of EPSS/KEV/PoC data, consistent with a non-trending, non-exploited issue.

An application using pybddisasm decodes an instruction, extracts an element from an INSTRUX array (such as an ND_OPERAND from the operands list), and keeps a reference to that element while allowing the parent INSTRUX object to be garbage-collected. When the application later reads from the retained element, it accesses freed memory, which either crashes the Python process or, if the freed allocation has been reused, exposes unrelated process memory. No public exploit identified at time of analysis.