Summary
Unbounded memory usage on exposed HTTP/2 (non-gRPC) endpoints
Workarounds
The vulnerability can be worked around entirely by including the http2server=0 value in the GODEBUG environment variable (see https://github.com/golang/go/issues/50058). This turns off HTTP/2 support on all non-gRPC endpoints. They will still function with HTTP/1.1.
The risk associated with this vulnerability can be somewhat mitigated by limiting the exposure of the endpoints in question. If necessary, vulnerable components or endpoints that are optionally configured can be disabled temporarily.
References
Impact
The net/http Go package has a reported vulnerability tracked under CVE-2021-44716 which allows attacker controlled HTTP/2 requests to trigger unbounded memory usage in HTTP/2 endpoints. gRPC endpoints are not vulnerable as they rely on their own HTTP/2 implementation instead of the net/http package. HTTP/2 endpoints consuming the net/http package within SPIRE server and agent (or other components in this repository) that are on by default include the following:
- OIDC Discovery Provider
- K8s Workload Registrar in webhook mode
The following endpoints are vulnerable when enabled:
- SPIRE server bundle endpoint (i.e. Federation API)
The following endpoints are NOT vulnerable, since HTTP/2 support in go is not enabled on non-TLS protected endpoints:
- SPIRE server/agent metrics endpoint when configured for Prometheus
- SPIRE server/agent health endpoints
- SPIRE server/agent profiling endpoints
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
SPIRE 1.0.3 and 1.1.3 have been released with an upgraded Go toolchain which patches the vulnerability
Frequently Asked Questions
- What is GHSA-M7VP-HQWV-7M5X? GHSA-M7VP-HQWV-7M5X is a high-severity security vulnerability in github.com/spiffe/spire (go), affecting versions < 1.0.3. It is fixed in 1.0.3, 1.1.3.
- Which versions of github.com/spiffe/spire are affected by GHSA-M7VP-HQWV-7M5X? github.com/spiffe/spire (go) versions < 1.0.3 is affected.
- Is there a fix for GHSA-M7VP-HQWV-7M5X? Yes. GHSA-M7VP-HQWV-7M5X is fixed in 1.0.3, 1.1.3. Upgrade to this version or later.
- Is GHSA-M7VP-HQWV-7M5X exploitable, and should I be worried? Whether GHSA-M7VP-HQWV-7M5X is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-M7VP-HQWV-7M5X is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-M7VP-HQWV-7M5X?
- Upgrade
github.com/spiffe/spireto 1.0.3 or later - Upgrade
github.com/spiffe/spireto 1.1.3 or later
- Upgrade