go-attestation: crafted TPM event log injects trusted SHA256 hashes, so a verifier accepts a compromised boot

CVSS 8.9CVE-2026-12681Firmware, BMC & network fabriccurated

Impact

parseEfiSignatureList() does not advance past the vendor bytes of a signature list before reading entries, so for SHA256 GUID lists attacker-controlled header bytes are appended to the list of trusted measurements. A machine submitting a crafted event log can get arbitrary hashes into the verifier's trusted database and have a boot state the verifier should reject be accepted as good. For an operator this undermines the thing attestation exists to do: a GPU node whose firmware or bootloader has been tampered with can still pass remote attestation and be admitted to the fleet, rejoin a tenant pool, or be handed workload keys. The integrity loss is in the verifier, not the node, so every node checked by an affected verifier is affected at once.

Who can reach it

Whoever controls the event log sent to the verifier - an attestation client, or anyone able to tamper with a node's measured boot and then have it attest. No authentication to the verifier beyond what the attestation flow already grants.

What to do

Upgrade go-attestation to 0.6.1 or later, rebuild every service that links it, and restart the attestation verifiers - a control-plane service rollout, not a node operation. Attestation results produced before the upgrade cannot be trusted; re-attest nodes afterwards.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-12681 https://github.com/google/go-attestation/security/advisories/GHSA-9r4w-jg96-92mv https://github.com/google/go-attestation/commit/b6e905e7ae52937f02b5ca494dd1c6a3ac7a1003 https://github.com/google/go-attestation/releases/tag/v0.6.1

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.