Dell iDRAC PLDM Heap Overflow

Executive summary #

The PLDM firmware-update parser on iDRAC9 and iDRAC10 contains heap-based out-of-bounds writes when 16-bit count or length fields exceed fixed buffer bounds. The parser runs in a root-privileged update daemon; code execution has not been assessed. This vulnerability has an estimated CVSSv3.1 score of CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N (3.1, Low), and is an instance of CWE-122 (Heap-based Buffer Overflow) and CWE-787 (Out-of-bounds Write).

Technical details #

The parser is reachable through two paths: an authenticated administrator with firmware-update privilege can upload a package through the Redfish UpdateService, where parsing occurs before signature verification; or a downstream MCTP endpoint (such as a NIC, PSU, GPU, or backplane) can return a crafted PLDM response without authentication or signature verification. The parser copies descriptor and component records into fixed-size arrays using 8-bit indices, while the count and length fields controlling those writes are 16-bit. On iDRAC9, the affected writes occur both during package parsing and while parsing downstream-device responses. On iDRAC10, the package parser (libpldmfwupdd.so.0, pldm_firmwarePackageParsing) checks only the package-header UUID format before parsing, and the downstream-device write paths also remain.

Attacker value #

This issue can allow a malicious or compromised on-bus device to corrupt heap memory in the root-privileged PLDM firmware-update daemon on the BMC. Whether the memory corruption can be driven to code execution has not been assessed. The device-response path requires a compromised or counterfeit component on the internal platform-management bus. The package-upload path requires an authenticated administrator with firmware-update privilege, but parsing occurs before package signature verification, so the signature check does not prevent the overflow. On iDRAC10, a 16-bit ComponentCount truncated to 8 bits in the loop guard can also cause continued out-of-bounds writes.

Credit #

This issue was discovered by HD Moore with the help of AI tools. Disclosure was coordinated by Tod Beardsley.

Timeline #

• 2026-07-16 (Thu): Initial findings discovered and documented
• 2026-07-21 (Tue): CVE-2026-65186 reserved
• 2026-08-27 (Thu): Vendor notified
• 2026-08-31 (Mon): Vendor acknowledged receipt, reserved CVE transferred
• 2026-10-26 (Mon): This public disclosure