EUVD-2026-38641
GHSA-9r4w-jg96-92mv
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Verifier ingests remote event log so AV:N/PR:N/UI:N; crafting a valid EFI_SIGNATURE_LIST that survives parsing raises AC:H; only integrity of attestation decisions is impacted.
Primary rating from Vendor (Google).
CVSS VectorVendor: Google
Lifecycle Timeline
2DescriptionCVE.org
Improper Validation of Specified Index, Position, or Offset in Input vulnerability in Google go-attestation. parseEfiSignatureList() does not advance the buffer past vendor bytes before reading entries. For hashSHA256SigGUID lists, this allows attacker-controlled vendor header bytes to be appended to the trusted SHA256 hash list. A crafted TPM event log could inject arbitrary SHA256 hashes into the verifier's trusted measurement database, enabling a remote attestation verifier to accept a compromised boot state. This issue affects go-attestation: through 0.6.0.
AnalysisAI
Trusted measurement-list poisoning in Google go-attestation through 0.6.0 lets a remote actor who controls a TPM event log fed to an attestation verifier inject arbitrary SHA256 hashes into the verifier's trusted hash database. Because parseEfiSignatureList() never advances past the EFI_SIGNATURE_LIST SignatureHeaderSize vendor bytes, those attacker-chosen bytes are accepted as legitimate hash entries, allowing a compromised boot state to be attested as healthy. No public exploit identified at time of analysis, but the fix is upstream in v0.6.1 and the root cause is documented in GHSA-9r4w-jg96-92mv.
Technical ContextAI
go-attestation is Google's Go library for TPM-based platform and remote attestation, commonly consumed by verifier services that ingest a measured-boot TCG event log and validate EFI Secure Boot signature databases (db/dbx/PK/KEK) embedded in those events. The flaw lives in attest/internal/events.go parseEfiSignatureList(), which parses EFI_SIGNATURE_LIST structures defined by UEFI specification section 31.4.1. Per spec, after the 28-byte fixed header there is a vendor-defined SignatureHeader region of SignatureHeaderSize bytes that must be skipped before signature entries begin; the buggy code initialized sigOffset to 0 for both the cert and hash entry loops, treating those vendor bytes as the first entry. For hashSHA256SigGUID lists, 48-byte entries (16-byte GUID + 32-byte hash) are emitted, so attacker-supplied vendor bytes become trusted hashes. This is CWE-1285 (Improper Validation of Specified Index, Position, or Offset) and only the single CPE cpe:2.3:a:google:go-attestation is affected.
RemediationAI
Upstream fix available in go-attestation v0.6.1 (https://github.com/google/go-attestation/releases/tag/v0.6.1) via commit b6e905e7ae52937f02b5ca494dd1c6a3ac7a1003, which adds a bound check rejecting SignatureHeaderSize values that meet or exceed the remaining list space and seeks past SignatureHeaderSize vendor bytes before both the certificate and hash entry loops; update go.mod to require at least v0.6.1 and rebuild and redeploy any verifier services. Review the advisory at https://github.com/google/go-attestation/security/advisories/GHSA-9r4w-jg96-92mv for full context. Until the upgrade is rolled out, compensating controls include refusing attestation evidence from untrusted endpoints, pinning the set of acceptable PCR measurements and SHA256 hashes out-of-band rather than relying on the parsed Secure Boot db, and rejecting event logs whose EFI_SIGNATURE_LIST entries contain a non-zero SignatureHeaderSize - the side effect is that some legitimate firmware-vendor event logs that legitimately populate the vendor header region will be discarded and may need manual exception handling.
Same technique Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today