pybddisasm EUVD-2026-115703

Exploitation requires an application built on the pybddisasm bindings to (1) obtain a structure-valued member of an INSTRUX object as a Python object, (2) retain that member reference while the parent INSTRUX allocation is freed (the member does not keep the parent alive), and (3) subsequently access the stale member. There is no remote or unauthenticated path: the CVSS vector is AV:L with PR:L, so a local authenticated context running the vulnerable code is needed. Realistic impact is limited by this dependence on a specific, somewhat unusual application coding pattern, and by the product's rare, unmaintained footprint; memory disclosure (versus a mere crash) further depends on whether the freed allocation has been reused.

This is a moderate-severity, low-urgency issue rather than a top priority. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) describes a locally-triggered, authenticated flaw whose primary impact is availability (VA:H, process crash) with only limited confidentiality exposure (VC:L, possible disclosure of reused freed memory) and no integrity impact (VI:N) - consistent with a use-after-free (CWE-416) in a Python binding. No EPSS score was supplied, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit was identified; exploitation status is 'no public exploit identified at time of analysis.' Critically, the flaw is not triggered by an external attacker against a service but by an application's own code pattern (retaining and later dereferencing a member after its parent INSTRUX object is freed), which sharply limits real-world attack surface. The vuln.today decision label 'this_month' aligns with a genuine-but-not-emergency posture. A complicating factor: the pybddisasm package is no longer maintained, so no vendor patch is expected - the only realistic remediation is a code/dependency change by consumers.

An application using pybddisasm decodes an instruction into an INSTRUX object, keeps a Python reference to one of its structure-valued members, and allows the parent INSTRUX object to be garbage-collected or otherwise freed. When the application later accesses the retained member, it reads memory the parent no longer owns, crashing the Python process or, if the freed allocation has been reused, exposing residual process memory. No public exploit code was identified; the only supplied reference is the PyPI project page.