Loading vulnerability…
Out-of-Bounds Read in openxc/isotp-c ISO-TP Single Frame Receive Handler
CVE-2026-37535 affects openxc/isotp-c through commit 5a5d19245f65189202719321facd49ce6f5d46ac. The vulnerability is an out-of-bounds read in the ISO-TP Single Frame receive handler. According to the provided content, the 4-bit payload length nibble from a received CAN ISO-TP Single Frame is used directly as the memcpy size without validating that the claimed payload length is consistent with the actual CAN data length present in the frame. As a result, a maliciously crafted CAN frame can advertise a larger payload length than is actually available, causing the implementation to read past the end of the frame buffer during copy/processing. The supporting context also indicates unsafe length handling in ISO 15765-2 frame processing and reassembly logic within isotp-c.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can cause an out-of-bounds memory read. The provided content states this may lead to denial of service and may also expose sensitive information from adjacent memory. Depending on how the library is integrated into an ECU, gateway, diagnostic tool, or other CAN-processing application, the bug could crash the process or leak memory contents that were not intended to be accessible to the attacker.
If you can’t patch tonight, do this now.
Until a patch is deployed, reduce exposure by filtering or rejecting malformed ISO-TP traffic at the CAN ingress point, especially Single Frames with inconsistent PCI length values. Limit acceptance of CAN traffic to trusted bus participants, isolate externally reachable CAN gateways and diagnostic interfaces, and add defensive validation in higher-level wrappers before passing frames to isotp-c. Runtime hardening such as ASan in testing, compiler hardening, and process isolation can reduce exploitability or improve detection, but they do not eliminate the underlying flaw.
Patch, then assume compromise.
Upgrade to a version of openxc/isotp-c that validates the ISO-TP Single Frame payload length nibble against the actual received CAN data length before performing memcpy or any equivalent buffer access. Specifically, the receive handler should reject frames whose declared payload length exceeds the bytes actually present after protocol overhead, and all copy operations should be bounded by the real frame length and destination buffer size. If no fixed release is available, patch the affected code derived from commit 5a5d19245f65189202719321facd49ce6f5d46ac or earlier to add strict length validation and negative/error-path handling for malformed frames.
No public exploits tracked yet. Mallory keeps watching.
3 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.