go-attestation CVE-2026-12681

Exploitation requires that a service consume go-attestation (through 0.6.0) as a remote attestation verifier and parse an EFI_SIGNATURE_LIST structure - typically delivered inside a TCG TPM event log - that originates from a host the attacker controls or can tamper with in transit; the malicious list must specify hashSHA256SigGUID as its SignatureType and a non-zero SignatureHeaderSize whose vendor bytes encode the attacker-chosen 16-byte GUID and 32-byte SHA256 hash. The attack is limited to verifier deployments that actually trust parsed Secure Boot databases for measurement decisions, requires the attacker to produce a well-formed event log that survives surrounding parsers (raising AC to High), and does not apply to platforms that ignore EFI signature lists or that pin trusted hashes out-of-band; no authentication, user interaction, or local access is required beyond control of the submitted event log.

Risk depends heavily on deployment: in any architecture where a verifier accepts attestation evidence from an untrusted or remote endpoint (the canonical use case for this library), the published CVSS:4.0 vector AV:N/AC:H/AT:N/PR:N/UI:N with VI:H and SI:H is realistic - there is no authentication or user interaction, but crafting a valid EFI_SIGNATURE_LIST that survives surrounding parsers raises complexity. Impact is squarely on integrity of attestation decisions (verifier trusts a compromised boot), with no confidentiality or availability loss, which matches the published 8.9 score. There is no CISA KEV listing, no EPSS score, and no public exploit identified at time of analysis, so this is a high-severity logic flaw with no evidence of in-the-wild abuse yet - but because it directly defeats the trust anchor of remote attestation, treat it as a priority for any service that consumes go-attestation event logs. Note one inconsistency worth verifying: the NVD-style description says "through 0.6.0" while the GHSA lists "<= 0.5.0 vulnerable, fixed in: None" yet the references include a v0.6.1 release tag and a merged patch commit - operators should confirm fixed-version pinning against the upstream release.

An attacker controlling a target endpoint (or a man-in-the-middle on the attestation channel) crafts a TPM event log containing an EFI_SIGNATURE_LIST whose SignatureHeader vendor region encodes a fake 16-byte GUID followed by the SHA256 hash of the attacker's tampered bootloader. When the verifier built on go-attestation parses that list, the vendor bytes are interpreted as the first signature entry, the tampered hash is added to the trusted measurement database, and the verifier subsequently accepts the compromised boot state as legitimate. No public exploit identified at time of analysis, but the regression test TestParseEfiSignatureListVendorHeaderNotTrusted in the fix commit demonstrates the exact byte layout needed.