Skip to content

chore(deps): update module google.golang.org/grpc to v1.83.2 [security] - #216

Merged
flemzord merged 1 commit into
mainfrom
renovate/security
Sep 10, 2026
Merged

flemzord merged 1 commit into
mainfrom
renovate/security

Conversation

@NumaryBot

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
google.golang.org/grpc require patch v1.83.1 -> v1.83.2

gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing :authority and Host headers

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj

More information

Details

A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).

Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.

This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.

  • Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
  • mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.
Impact

An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.

Patches

The issue has been addressed in master (and backported to 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.

Severity

High

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Release Notes

grpc/grpc-go (google.golang.org/grpc)

v1.83.2: Release 1.83.2

Compare Source

Security


Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@NumaryBot
NumaryBot requested a review from a team as a code owner September 9, 2026 02:09
@NumaryBot
NumaryBot enabled auto-merge (squash) September 9, 2026 02:09
@NumaryBot

Copy link
Copy Markdown
Contributor Author

✅ Approve — automated review

The patch consistently updates gRPC from v1.83.1 to v1.83.2 in go.mod and go.sum. No correctness issues are evident.

No findings.

@flemzord
flemzord merged commit e1b6922 into main Sep 10, 2026
10 of 15 checks passed
@flemzord
flemzord deleted the renovate/security branch September 10, 2026 09:43
@shipfox-ai

shipfox-ai Bot commented Sep 18, 2026

Copy link
Copy Markdown

This PR is a minimal, well-formed Renovate security bump of google.golang.org/grpc from v1.83.1 to v1.83.2 (CVE-2026-84445 / GHSA-2v4p-qf9q-27wj, a high-severity xDS-server DoS). The diff contains exactly three changed lines across go.mod and go.sum; I verified against the checkout that the v1.83.2 pin and both checksum entries are present and that no stale v1.83.1 references remain anywhere in the repository. The repo's own code uses standard gRPC server/client paths (e.g. internal/module.go, cmd/root.go) rather than xds.NewGRPCServer, so the change is non-breaking for this codebase while still applying the security fix. Both the Standards and Spec axes were independently reviewed with no material findings. Recommendation: approve.

Standards

No confirmed material finding. The repository documents no coding standards (no CODING_STANDARDS.md, CONTRIBUTING.md, AGENTS.md, or equivalent), so there are no documented rules to violate. The go.mod require-block hunk (go.mod:21) stays alphabetically ordered and the go.sum hunk (go.sum:309-310) is the mechanically required checksum update; the two-file shape is the minimal, conventional form of a Go module bump. None of the baseline smells (naming, duplication, coupling, speculative generality, etc.) apply to a version-string change with no code touched.

Spec

No confirmed material finding. The spec (Renovate PR body) requires a single patch bump v1.83.1 -> v1.83.2 of google.golang.org/grpc, driven by CVE-2026-84445 / GHSA-2v4p-qf9q-27wj (DoS via crafted requests missing both :authority and Host headers against xds.NewGRPCServer servers). The diff fully satisfies it:

  • go.mod:21: - google.golang.org/grpc v1.83.1 / + google.golang.org/grpc v1.83.2 — exactly the required target version.
  • go.sum:309-310: both the module hash (h1:EManeRomTObA0BU7I8vXgg/78uE5MJ9M8B39EX2WscU=) and the /go.mod hash (h1:YPI1hK3kDked6iHvgX3tR0y+nX/qpMFKhPgFsokw1S8=) were regenerated for v1.83.2 together, consistent with a go get/go mod tidy bump; a repo-wide search confirms no stale v1.83.1 entries remain.

No missing requirements, no scope creep (only the three grpc lines changed; adjacent genproto/protobuf lines are untouched context), and no wrong implementations. Nothing missing, nothing extra, nothing incorrect.

Reviewed independently by GLM (glm-5.3-flash) and DeepSeek (deepseek-v4-pro-0813) via Shipfox; verified and synthesized by GLM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

2 participants