Threats affecting pkg:golang/github.com/google/go-attestation

An uncontrolled recursion vulnerability in the Windows SIPA event log parser of Google go-attestation versions up to and including 0.6.1 allows an attacker to cause a denial of service (DoS). The (*WinEvents).readELAMAggregation function recurses for every nested elamAggregation sub-event without enforcing a maximum recursion depth limit, while the size guard is bypassed on recursive execution paths. By submitting a crafted Windows event log containing deeply nested elamAggregation headers, an attacker can exhaust the goroutine call stack, triggering an unrecoverable fatal runtime error (stack overflow) that immediately crashes the verifier application.

## Summary `parseEfiSignatureList()` in `attest/internal/events.go` does not skip `SignatureHeaderSize` vendor bytes before reading `EFI_SIGNATURE_LIST` signature entries, violating UEFI specification section 31.4.1. ## Impact For `hashSHA256SigGUID` lists, attacker-controlled vendor header bytes are appended directly to the trusted SHA256 hash list. A crafted TPM event log can inject arbitrary SHA256 hashes into the verifier's trusted measurement database, allowing a remote attestation verifier to accept a compromised boot state as legitimate — breaking the core integrity guarantee of remote attestation. ## Root Cause After `binary.Read(&signatures.Header)` reads 28 bytes, `buf` points to the start of the `SignatureHeaderSize` vendor bytes. Both entry loops start at `sigOffset := 0` instead of `sigOffset := SignatureHeaderSize`, causing vendor bytes to be read as signature entries. ## Affected versions All versions through commit `f877374` (2026-05-15). ## Fix Pull request: https://github.com/google/go-attestation/pull/502 - Add bound check: `SignatureHeaderSize` must not exceed remaining list space - Skip `SignatureHeaderSize` bytes before both entry loops - Regression test: `TestParseEfiSignatureListNonZeroSignatureHeaderSize`