CVE-2026-19201 is a high severity (CVSS 7.5) uncontrolled recursion in the Windows event log parser of Google go-attestation, versions up to and including 0.6.1. A crafted log with deeply nested elamAggregation events crashes the verifier with a stack overflow. Version v0.6.2 fixes it.
What's affected
The GitHub advisory GHSA-hcm6-rjfh-f25p lists github.com/google/go-attestation v0.6.1 and earlier as affected, and v0.6.2 as patched. It rates the issue High with a CVSS 3.1 score of 7.5 and an availability only impact.
The advisory lists no workaround. It explains that the stack overflow in Go is a fatal runtime error that recover cannot catch, so applications cannot handle it in their own code. Upgrading is the only remedy it points to.
The advisory text we read says no CVE had been assigned when it was written, while the record carries CVE-2026-19201. The fix is in pull request 506 and in the v0.6.2 release.
How to check if you're exposed
Check which version your Go module uses:
go list -m github.com/google/go-attestation
Run it in every module that might import the library, directly or through another dependency. To see why it is present, use:
go mod why -m github.com/google/go-attestation
Then check whether your code parses Windows event logs submitted by clients. The flaw sits in the Windows SIPA event log parser, so only services that verify attestation from Windows machines and reach this parser are exposed. A dependency scan flags the version, and reachability analysis tells you whether the parser is called.
What to do now
- Find modules that depend on github.com/google/go-attestation, directly or indirectly.
- Update to v0.6.2 with go get github.com/google/go-attestation@v0.6.2, then run go mod tidy.
- Rebuild and redeploy the services that embed the library.
- Run attestation verifiers under a supervisor that restarts them, so a crash is short.
- Limit who can submit event logs to your verifier and rate limit submissions.
- Add the version check to your CI so older versions are flagged.
Why it matters
The weakness class is CWE-674, uncontrolled recursion. The function that reads aggregated events calls itself for every nested sub-event and has no depth limit. A size check that should bound the work is skipped on the recursive paths. A log made of many nested headers makes the call stack grow until the Go runtime stops the process.
The key point for defenders is that a Go stack overflow is not a panic you can catch. It ends the process. A remote client that can send a log to a verifier can therefore stop the service with one request, which is why the availability impact is high. The fix adds a limit on depth and applies the size bound correctly. KEV status is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can I catch this crash in my code?
No. The advisory explains a Go stack overflow is a fatal error that recover cannot catch, so upgrade the library.
Is my service affected if it only imports the library?
The flaw is in the Windows SIPA event log parser. Check whether your code reaches that parser before you set priority, but upgrade regardless.
Sources
Last reviewed: 18 October 2026.
