CVE-2026-118444 in pybddisasm
Summary
by MITRE • 11/03/2026
Out-of-bounds read vulnerabilities in the pybddisasm Python bindings may disclose adjacent process memory during instruction decoding. The nd_decode function may read up to 15 bytes without checking the actual length of the supplied Python buffer. The nd_decode_ex, nd_decode_ex2, and nd_decode_with_context functions pass the caller-supplied buffer size to the decoder without validating it against the actual length of the Python buffer. Data read beyond the buffer may be exposed through nd_get_instrux_bytes, which returns a fixed-length list of 16 bytes. Exploitation requires an application to invoke the affected APIs with a short buffer or an oversized length and to expose the resulting bytes to an attacker. The pybddisasm package is no longer maintained.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in the pybddisasm Python bindings represents a critical out-of-bounds read flaw that compromises memory safety during instruction decoding operations. This issue stems from insufficient validation of buffer lengths within several core functions, specifically nd_decode, nd_decode_ex, nd_decode_ex2, and nd_decode_with_context. These functions are designed to process binary data for disassembly purposes but fail to verify whether the length parameter provided by the caller accurately reflects the actual size of the Python buffer being passed. In the case of the nd_decode function, it may attempt to read up to fifteen bytes from memory without performing any bounds checking against the true extent of the supplied buffer. Similarly, the other affected functions blindly pass the caller-supplied buffer size directly to the underlying decoder logic, bypassing necessary validation steps that would ensure the requested data does not exceed available memory boundaries.
The operational impact of this flaw is significant because it allows for the disclosure of adjacent process memory contents. When an application invokes these APIs with a short buffer or specifies an oversized length parameter, the decoding engine proceeds to read bytes from memory locations immediately following the intended buffer boundary. This excess data is then exposed through the nd_get_instrux_bytes function, which returns a fixed-length list comprising sixteen bytes. Consequently, if the input buffer is smaller than this return size, the remaining slots in the returned list will be populated with whatever data resides in adjacent memory addresses. An attacker who can control or influence the inputs to these functions could potentially extract sensitive information such as stack cookies, cryptographic keys, internal application state, or other confidential data residing in the process's virtual address space that lies beyond the allocated buffer region.
From a classification perspective, this vulnerability aligns with CWE-125, which describes Out-of-bounds Read scenarios where software reads past the end of a memory buffer. The exploitation vector typically involves an attacker inducing the application to execute code paths that trigger these specific decoding functions with malformed inputs. This behavior is consistent with techniques observed in ATT&CK tactic TA0043, specifically relating to Collection and Exfiltration over C2 channels if the leaked data can be transmitted externally. While direct remote code execution is not implied by an out-of-bounds read alone, the leakage of memory contents constitutes a severe confidentiality breach that can facilitate further attacks such as bypassing security mitigations like ASLR or extracting session tokens.
Given that the pybddisasm package is no longer maintained, remediation through standard patching mechanisms is not feasible for users relying on this specific library version. Organizations and developers currently utilizing these bindings must prioritize immediate mitigation strategies to reduce exposure risk. The most effective approach involves replacing the vulnerable component with a actively maintained alternative disassembly engine that adheres to strict memory safety standards. If migration is temporarily impossible, applications should implement rigorous input validation at the Python layer before passing data to any of the affected C-extension functions. This includes verifying that the length parameter exactly matches or does not exceed the actual byte length of the buffer object and ensuring that nd_get_instrux_bytes outputs are handled with caution to prevent accidental exposure of raw memory dumps in logs or network responses. Additionally, deploying runtime application self-protection tools or using languages with automatic bounds checking for critical security components can help detect such anomalies during testing phases before they reach production environments.