DMTF libspdm: Missing integrity coverage of OpaqueData in FINISH transcript
Summary
libspdm is a reference implementation of the DMTF SPDM protocol, used to secure communication between devices such as host processors and firmware components. In version 1.4.0, the FINISH and FINISH_RSP transcripts used for signatures and HMACs do not cover the new OpaqueDataLength and OpaqueData fields. An adjacent attacker in an active man-in-the-middle position on an SPDM session could modify the opaque data in transit without the signature or HMAC check failing. Confidentiality and availability are not affected.
Affected
- DMTF libspdm 1.4.0
- FINISH and FINISH_RSP transcripts (signature and HMAC) of SPDM 1.4 implementations
Fixed in
- Fixed in libspdm 1.4.1 (DSP0274 1.4.1 specification).
Workaround
- No vendor-documented workaround.
- Limit SPDM traffic to trusted, controlled links until the affected firmware is updated.
Exploitation
- No known exploitation.
- No public proof of concept found.
- Not listed in the CISA KEV catalog.
Our recommendation
- Check whether your hardware, BMC or firmware products use libspdm 1.4.0.
- Ask vendors when they will ship builds based on libspdm 1.4.1 and apply them.
- Until patched, restrict SPDM traffic to trusted links.
- Priority: low to medium, as an active man-in-the-middle position on the SPDM link is required.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- libspdm issue #3633 github.com
- DMTF-2026-0003 GitHub Security Advisory github.com
- CVE Record CVE-2026-61810 www.cve.org
- VulDB CVE-2026-61810 vuldb.com
- VulDB entry 435606 vuldb.com
- OpenCVE CVE-2026-61810 app.opencve.io
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 11 Nov 2026, 14:42.
Original description (NVD)
libspdm is a sample implementation that follows the DMTF SPDM specifications. In version 1.4.0, both the FINISH request (Table 80) and the FINISH_RSP response (Table 81) gained two new fields, OpaqueDataLength and OpaqueData, placed before the trailing signed/authenticated field. The transcript definitions used to compute and verify the FINISH signature, the FINISH HMAC (RequesterVerifyData), and the FINISH_RSP HMAC (ResponderVerifyData) were not updated and still terminate with a step of the form. Per DSP0274, the "SPDM Header Fields" are only the four header bytes (SPDMVersion, RequestResponseCode, Param1, Param2). A literal reading therefore excludes OpaqueDataLength and OpaqueData, even though those fields are transmitted before the trailing signature/HMAC field. Because the signature/HMAC must cover every field transmitted before it to "protect the entire handshake against manipulation by an active attacker," an active attacker could otherwise modify the opaque data in flight without invalidating the signature or HMAC. This issue has been patched in version 1.4.1.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.