CVE-2026-61810

Description

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.

Is your site exposed to CVE-2026-61810?

Run a free security scan — no signup, results in seconds.

Weakness Type (CWE)

CWE-325 CWE-325

References

Other References

https://github.com/DMTF/libspdm/issues/3633 https://github.com/DMTF/libspdm/security/advisories/GHSA-chjj-xvqx-c8w4

Frequently Asked Questions

What is CVE-2026-61810? +

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.

How do I check if I'm vulnerable to CVE-2026-61810? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-107785

Crux Agent from 1.9.0 before 2.0.3 uses the full SKA bilocation key as the WireGuard preshared key. When a peering …

CVE-2025-30147

Besu Native contains scripts and tooling that is used to build and package the native libraries used by the Ethereum …

CVE-2026-48480

The netty incubator codec.bhttp is a java language binary http parser. Prior to version 0.0.22.FInal, the codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp …

CVE-2026-76784

Multiple TP-Link Kasa smart home devices contain insufficient cryptographic protections in the local device communication protocol. An adjacent network attacker …

CVE-2026-88823

Issue summary: The AES-GCM-SIV implementation treats a zero-length Additional Authenticated Data (AAD) update as a reset of all the AAD …

CVE-2025-58359

ZF FROST is a Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures). In versions 2.0.0 through 2.1.0, refresh shares …