pybddisasm EUVD-2026-115701

Exploitation requires a consuming application built on pybddisasm (≤0.3.0) to call one of nd_decode, nd_decode_ex, nd_decode_ex2, or nd_decode_with_context, encounter an unsuccessful decode (including failures from invalid parameters), and then access and expose the members of the returned INSTRUX object whose contents were never initialized. The decisive limiting factor is that the flaw is inert unless the application reads and surfaces that object after a failed decode - a well-written caller that checks the decode status first is unaffected. Further limits: the CVSS vector is local (AV:L) and requires some privilege (PR:L), impact is confined to confidentiality (information disclosure of residual process memory) with no integrity or availability impact, and the package is unmaintained with no fixed version available.

This is a genuinely low-priority issue despite being a real memory-disclosure bug. All signals point the same direction: the input CVSS 4.0 vector is AV:L (local), AC:L, AT:N, PR:L (requires some privilege/authenticated context) and only VC:L confidentiality impact with no integrity or availability impact, yielding a modest base score of 4.8. The vuln.today decision label is 'monitor', not act_now or emergency. There is no CISA KEV listing and no EPSS score was supplied, so there is no evidence of active or probable exploitation. No exploit or PoC reference appears in the input, so no public exploit is identified. Crucially, exploitation is not self-contained: the flaw only matters if a downstream application reads and exposes the members of an INSTRUX object returned after a FAILED decode, so the consuming application must behave in a specific insecure way. Combined with the fact that pybddisasm is an unmaintained, niche library, this reads as a low-real-risk medium-CVSS issue rather than an urgent threat. No signals conflict here.

A local, low-privileged user interacts with an application that uses pybddisasm and feeds it input that causes nd_decode/nd_decode_ex/nd_decode_ex2/nd_decode_with_context to fail (e.g. invalid parameters or an undecodable instruction). The application then reads fields of the returned, uninitialized INSTRUX object and surfaces them, leaking residual process memory to the user. No public exploit code or PoC is identified in the available data.