CVE-2026-12681: Google go-attestation RCE Vulnerability

CVE-2026-12681 Overview

CVE-2026-12681 affects Google's go-attestation library through version 0.6.0. The vulnerability resides in the parseEfiSignatureList() function, which fails to advance the buffer past vendor bytes before reading signature entries. For hashSHA256SigGUID lists, attacker-controlled vendor header bytes are appended to the trusted SHA256 hash list. A crafted Trusted Platform Module (TPM) event log can inject arbitrary SHA256 hashes into the verifier's trusted measurement database. This allows a remote attestation verifier to accept a compromised boot state as legitimate, defeating the integrity guarantees of remote attestation [CWE-1285].

Critical Impact
Remote attackers can inject arbitrary SHA256 hashes into the trusted measurement database, causing remote attestation verifiers to validate compromised boot states.

Affected Products

Google go-attestation library versions through 0.6.0
Remote attestation verifiers depending on go-attestation for EFI signature parsing
Systems consuming TPM event logs via the affected library

Discovery Timeline

2026-06-24 - CVE-2026-12681 published to the National Vulnerability Database (NVD)
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-12681

Vulnerability Analysis

The go-attestation library parses Extensible Firmware Interface (EFI) signature lists from TPM event logs to reconstruct a verifier's trusted measurement state. The parseEfiSignatureList() function reads entries from an EFI_SIGNATURE_LIST structure but does not correctly account for the variable-length SignatureHeader field that follows the list header. When the function processes a list identified by hashSHA256SigGUID, it begins reading signature entries directly without first advancing the buffer cursor past the vendor header bytes.

Because the parser misaligns its read offset, attacker-controlled bytes from the vendor header are interpreted as legitimate SHA256 hash entries. These spurious hashes are then appended to the verifier's trusted hash database. The flaw breaks the trust boundary that remote attestation relies on, since the verifier cannot distinguish injected hashes from those originating in a genuine, signed firmware database.

Root Cause

The root cause is improper validation of an index, position, or offset in input data [CWE-1285]. The parsing logic skips the SignatureHeaderSize field when computing the start offset of the first signature, treating the vendor header bytes as the first signature entry rather than as opaque metadata to be skipped.

Attack Vector

An attacker who can supply a crafted TPM event log to a service using go-attestation can manipulate the verifier's view of the boot state. Since the attack vector is network-based and requires no authentication, any remote attestation service that consumes attacker-supplied event logs is exposed. The attacker chooses hashes that match the measurements of a compromised bootloader or kernel image, causing the verifier to accept the compromised state. See the GitHub Security Advisory GHSA-9r4w-jg96-92mv for additional technical detail.

Detection Methods for CVE-2026-12681

Indicators of Compromise

Unexpected SHA256 entries appearing in attestation verifier trust databases that do not correspond to known-good firmware measurements
TPM event logs containing EFI_SIGNATURE_LIST structures with non-zero SignatureHeaderSize values combined with hashSHA256SigGUID list types
Remote attestation success for endpoints whose boot measurements should not match the verifier's policy

Detection Strategies

Audit verifier source code and dependency manifests (go.mod, go.sum) for go-attestation versions at or below 0.6.0
Compare attested boot measurements against a separately maintained golden baseline of expected PCR values and signature lists
Log and review all signature lists parsed during attestation, flagging entries appended after a non-zero-length signature header

Monitoring Recommendations

Capture attestation decisions and the parsed signature list contents in centralized logging for correlation
Alert on attestation passes from hosts whose firmware or boot configuration was recently modified
Track go-attestation library versions across the build pipeline and flag deployments using vulnerable releases

How to Mitigate CVE-2026-12681

Immediate Actions Required

Upgrade go-attestation to version 0.6.1 or later in all services that parse TPM event logs
Rebuild and redeploy any binaries that statically link go-attestation, since updating the source dependency alone is not sufficient
Re-validate recent attestation results from production verifiers to identify boot states that may have been incorrectly accepted

Patch Information

The issue is fixed in go-attestation v0.6.1. Review the GitHub Release v0.6.1 notes and the GitHub Commit Details for the exact code change that advances the buffer past the signature header bytes before parsing entries.

Workarounds

Restrict attestation services to only accept event logs from authenticated, trusted endpoints until the patched library is deployed
Apply strict policy enforcement on PCR values and pre-validated signature list contents out-of-band rather than relying solely on parsed event log contents
Reject event logs containing EFI_SIGNATURE_LIST structures with non-zero SignatureHeaderSize fields if upstream firmware is known to produce zero-length signature headers

bash

# Update go-attestation to the patched release
go get github.com/google/go-attestation@v0.6.1
go mod tidy
go build ./...