Skip to content

Update module google.golang.org/grpc to v1.83.1 [SECURITY] - #18

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/go-google.golang.org-grpc-vulnerability
Open

Update module google.golang.org/grpc to v1.83.1 [SECURITY]#18
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/go-google.golang.org-grpc-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 9, 2024 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
google.golang.org/grpc v1.53.0 → v1.83.1 age confidence

gRPC-Go HTTP/2 Rapid Reset vulnerability

GHSA-m425-mq94-257g

More information

Details

Impact

In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.

Patches

This vulnerability was addressed by #​6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.

Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection.

Workarounds

None.

References

#​6703

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

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

gRPC-Go has an authorization bypass via missing leading slash in :path

CVE-2026-33186 / GHSA-p77j-4mvh-x3m3

More information

Details

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:

  1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
  2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer):

  • v1.79.3
  • The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Severity

  • CVSS Score: 9.1 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

References

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

gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

GHSA-hrxh-6v49-42gf

More information

Details

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

  • Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
  • Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
  • Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.
Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers
  • Affected Component: xDS RBAC
  • Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
    • If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
  • If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
  • Affected Component: HTTP/2 transport
  • Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
  • Affected Component: xDS RBAC
  • Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

Has the problem been patched? What versions should users upgrade to?

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

  • For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
  • For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Severity
Vulnerability Qualitative Severity Approximate CVSS v3.1 Score Primary Impact
xDS RBAC Authorization Bypass High 8.2 Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass High 7.5 High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic Medium 5.9 Process Crash / Denial of Service

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

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

gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation

CVE-2026-84304 / GHSA-vp52-pcj8-j9qc

More information

Details

Impact

An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches

The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds

This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

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

gRPC-Go HTTP/2 Rapid Reset vulnerability

GHSA-m425-mq94-257g / GO-2023-2153

More information

Details

Impact

In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.

Patches

This vulnerability was addressed by #​6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.

Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection.

Workarounds

None.

References

#​6703

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

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

Denial of service from HTTP/2 Rapid Reset in google.golang.org/grpc

GHSA-m425-mq94-257g / GO-2023-2153

More information

Details

An attacker can send HTTP/2 requests, cancel them, and send subsequent requests. This is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit, grpc.MaxConcurrentStreams. This results in a denial of service due to resource consumption.

Severity

Unknown

References

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

gRPC-Go has an authorization bypass via missing leading slash in :path

CVE-2026-33186 / GHSA-p77j-4mvh-x3m3 / GO-2026-4762

More information

Details

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:

  1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
  2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer):

  • v1.79.3
  • The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Severity

  • CVSS Score: 9.1 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

References

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

Authorization bypass in gRPC-Go via missing leading slash in :path in google.golang.org/grpc

CVE-2026-33186 / GHSA-p77j-4mvh-x3m3 / GO-2026-4762

More information

Details

Authorization bypass in gRPC-Go via missing leading slash in :path in google.golang.org/grpc

Severity

Unknown

References

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

gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

GHSA-hrxh-6v49-42gf / GO-2026-6061

More information

Details

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

  • Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
  • Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
  • Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.
Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers
  • Affected Component: xDS RBAC
  • Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
    • If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
  • If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
  • Affected Component: HTTP/2 transport
  • Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
  • Affected Component: xDS RBAC
  • Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

Has the problem been patched? What versions should users upgrade to?

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

  • For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
  • For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Severity
Vulnerability Qualitative Severity Approximate CVSS v3.1 Score Primary Impact
xDS RBAC Authorization Bypass High 8.2 Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass High 7.5 High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic Medium 5.9 Process Crash / Denial of Service

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

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

Vulnerabilities in the xDS RBAC authorization engine and the HTTP/2 transport server implementation in google.golang.org/grpc

GHSA-hrxh-6v49-42gf / GO-2026-6061

More information

Details

Vulnerabilities in the xDS RBAC authorization engine and the HTTP/2 transport server implementation in google.golang.org/grpc

Severity

Unknown

References

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

gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation

CVE-2026-84304 / GHSA-vp52-pcj8-j9qc

More information

Details

Impact

An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches

The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds

This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

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.1: Release 1.83.1

Compare Source

Security

  • xds/rbac: Fix a bug where nested Principal or Permission rules with :scheme or grpc- prefixed header matchers were not rejected, which could cause DENY rules to fail open. (#​9258)
  • xds/rbac: Fix a bug where the host header matcher was not being replaced with :authority in nested Principal or Permission rules. (#​9258)
  • xds/rbac: Fix a bug where a header matcher whose name was not lowercase, such as X-Role, matched no header, which could cause DENY rules to fail open. (#​9332)
  • xds/rbac: Fix a bug where a :scheme or grpc- prefixed header matcher was accepted when its name was not lowercase. (#​9332)
  • xds/rbac: Fix a bug where a Host header matcher was not replaced with :authority. (#​9332)

Performance

  • transport: Restrict memory overhead of buffering small data frames. (#​9331)

v1.83.0: Release 1.83.0

Compare Source

Security

  • server: Stop reading from connections when flooded by HTTP/2 frames to mitigate resource exhaustion. The default value for this limit is 100 frames, excluding DATA and HEADERS, and may be changed by setting environment variable GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT.
  • xds/rbac: Support Metadata and RequestedServerName permissions matcher fields. If present in a DENY rule, previously these would be ignored and fail-open.
  • xds/rbac: Fix panic when parsing unsupported fields in NotRule/NotId permissions.
  • xds/rbac: Support the deprecated source_ip principal identifier by treating it as equivalent to direct_remote_ip.
  • xds: Fix panic when parsing route header matchers configured with empty exact_match, prefix_match, or suffix_match strings. (#​9223)

New Features

  • xds/googlec2p: Enable DirectPath over Interconnect support for on-premises clients via the force-xds target URI query parameter. (#​9133)
  • xds: Enable xDS configuration to control which fields get propagated from ORCA backend metric reports to LRS load reports. (#​9145)
  • authz: Add OnPolicyUpdate callback to FileWatcherOptions to notify when an authz policy is loaded or updated. (#​9142)
  • xds: Add support for the GCP Authentication HTTP Filter, which automatically fetches and attaches GCP Service Account Identity JWT tokens to outgoing RPCs.
    • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_GCP_AUTHENTICATION_FILTER=true. (#​9119)
  • xds: Add support for xDS-based HTTP CONNECT proxies.
    • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_HTTP_CONNECT=true. (#​9151)
  • xds: Add support for contains_match in route header matchers. (#​9223)

Bug Fixes

  • credentials/alts: Fix panic when processing malformed frames by validating that the message frame length exceeds the message type field size. (#​9197)
  • grpc: Fix compilation on Plan 9 targets (GOOS=plan9), broken since v1.81.0. (#​9255)

v1.82.2: Release 1.82.2

Compare Source

Security

  • server: Reject requests missing both :authority and Host headers with HTTP 400 and status Internal. (#​9365)

v1.82.1: Release 1.82.1

Compare Source

Security

  • server: Stop reading from the connection when flooded by HTTP/2 frames. The default value for this limit is 100 frames, excluding DATA and HEADERS, and may be changed by setting environment variable GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT.
  • xds/rbac: Support Metadata and RequestedServerName permissions matcher fields. If present in a DENY rule, previously these would be ignored and fail-open.
  • xds/rbac: Fix panic when parsing unsupported fields in NotRule/NotId permissions.
  • xds/rbac: Support the deprecated source_ip principal identifier by treating it as equivalent to direct_remote_ip.

v1.82.0: Release 1.82.0

Compare Source

Behavior Changes

  • server: Remove support for GRPC_GO_EXPERIMENTAL_DISABLE_STRICT_PATH_CHECKING environment varibale. Strict incoming RPC path validation (which has been the default since v1.79.3) can no longer be disabled. (#​9112)
  • transport: Add environment variable to change the default max header list size from 16MB to 8KB. This may be enabled by setting GRPC_GO_EXPERIMENTAL_ENABLE_8KB_DEFAULT_HEADER_LIST_SIZE=true. This will be enabled by default in a subsequent release. (#​9019)
  • balancer: Load Balancing policy registry is now case-sensitive. Set GRPC_GO_EXPERIMENTAL_CASE_SENSITIVE_BALANCER_REGISTRIES=false (and file an issue) to revert to case-insensitive behavior. (#​9017)

New Features

  • experimental/stats: Expose a new API, NewContextWithLabelCallback, to register a callback that is invoked when telemetry labels are added. (#​8877)
  • client: Return a portion of the response body in the error message, when the client receives an unexpected non-gRPC HTTP response, to make debugging easier. (#​8929)
  • server: Add environment variable GRPC_GO_SERVER_GOROUTINE_LABELS that controls setting runtime/pprof.Labels on goroutines spawned by the server. Set GRPC_GO_SERVER_GOROUTINE_LABELS=grpc.method=true to add the grpc.method label on goroutines spawned to handle incoming requests. (#​9082)

Bug Fixes

  • xds/server: Fix a memory leak of HTTP filter instances occurring when route configurations are updated in-place during a Route Discovery Service (RDS) update. (#​9138)
  • grpc: In the deprecated gzip Compressor (used via the deprecated WithCompressor dial option), enforce the MaxRecvMsgSize limit on the decompressed message buffer, preventing excessive memory allocation from highly compressed payloads. (#​9114)
  • stats/opentelemetry: Record retry attempts, grpc.previous-rpc-attempts, at the call level and not the attempt level. (#​8923)
  • encoding: Ensure Close() is always called on readers returned from Compressor.Decompress if possible. (#​9135)
  • channelz: Fix the LastMessageSentTimestamp and LastMessageReceivedTimestamp fields in SocketMetrics to ensure they contain correct timestamp values. (#​9109)

v1.81.1: Release 1.81.1

Compare Source

Security

  • xds/rbac: Fix a potential authorization bypass caused by incorrectly falling through URI/DNS SANs to Subject Distinguished Name (DN) when matching the authenticated principal name. With this fix, only the first non-empty identity source will be used, as per gRFC A41. (#​9111)

v1.81.0: Release 1.81.0

Compare Source

Behavior Changes

  • balancer/rls: Switch gauge metrics to asynchronous emission (once per collection cycle) to reduce telemetry noise and align with other gRPC language implementations. (#​8808)

Dependencies

  • Minimum supported Go version is now 1.25. (#​8969)

Bug Fixes

  • xds: Use the leaf cluster's security config for the TLS handshake instead of the aggregate cluster's config. (#​8956)
  • transport: Send a RST_STREAM when receiving an END_STREAM when the stream is not already half-closed. (#​8832)
  • xds: Fix ADS resource name validation to prevent a panic. (#​8970)

New Features

  • grpc/stats: Add support for custom labels in per-call metrics (gRFC A108). (#​9008)
  • xds: Add support for Server Name Indication (SNI) and SAN validation (gRFC A101). Disabled by default. To enable, set GRPC_EXPERIMENTAL_XDS_SNI=true environment variable. (#​9016)
  • xds: Add support to control which fields get propagated from ORCA backend metric reports to LRS load reports (gRFC A85). Disabled by default. To enable, set GRPC_EXPERIMENTAL_XDS_ORCA_LRS_PROPAGATION=true. (#​9005)
  • xds: Add metrics to track xDS client connectivity and cached resource state (gRFC A78). (#​8807)
  • stats/otel: Enhance grpc.subchannel.disconnections metric by adding disconnection reason to the grpc.disconnect_error label (gRFC A94). This provides granular insights into why subchannels are closing. (#​8973)
  • mem: Add mem.Buffer.Slice() API to slice the buffer like a slice. (#​8977)

Performance Improvements

  • alts: Pool read buffers to lower memory utilization when sockets are unreadable. (#​8964)
  • transport: Pool HTTP/2 framer read buffers to reduce idle memory consumption. Currently limited to Linux for ALTS and non-encrypted transports (TCP, Unix). To disable, set GRPC_GO_EXPERIMENTAL_HTTP_FRAMER_READ_BUFFER_POOLING=false and report any issues. (#​9032)

v1.80.0

Compare Source

v1.79.3: Release 1.79.3

Compare Source

Security

  • server: fix an authorization bypass where malformed :path headers (missing the leading slash) could bypass path-based restricted "deny" rules in interceptors like grpc/authz. Any request with a non-canonical path is now immediately rejected with an Unimplemented error. (#​8981)

v1.79.2: Release 1.79.2

Compare Source

Bug Fixes

  • stats: Prevent redundant error logging in health/ORCA producers by skipping stats/tracing processing when no stats handler is configured. (#​8874)

v1.79.1: Release 1.79.1

Compare Source

Bug Fixes

  • grpc: Remove the -dev suffix from the User-Agent header. (#​8902)

v1.79.0: Release 1.79.0

Compare Source

API Changes

  • mem: Add experimental API SetDefaultBufferPool to change the default buffer pool. (#​8806)
  • experimental/stats: Update MetricsRecorder to require embedding the new UnimplementedMetricsRecorder (a no-op struct) in all implementations for forward compatibility. (#​8780)

Behavior Changes

  • balancer/weightedtarget: Remove handling of Addresses and only handle Endpoints in resolver updates. (#​8841)

New Features

  • experimental/stats: Add support for asynchronous gauge metrics through the new AsyncMetricReporter and RegisterAsyncReporter APIs. (#​8780)
  • pickfirst: Add support for weighted random shuffling of endpoints, as described in gRFC A113.
    • This is enabled by default, and can be turned off using the environment variable GRPC_EXPERIMENTAL_PF_WEIGHTED_SHUFFLING. (#​8864)
  • xds: Implement :authority rewriting, as specified in gRFC A81. (#​8779)
  • balancer/randomsubsetting: Implement the random_subsetting LB policy, as specified in gRFC A68. (#​8650)
  • server: Include status detail headers, if available, when terminating a stream during request header processing. (#​8754)

Bug Fixes

  • credentials/tls: Fix a bug where the port was not stripped from the authority override before validation. (#​8726)
  • xds/priority: Fix a bug causing delayed failover to lower-priority clusters when a higher-priority cluster is stuck in CONNECTING state. (#​8813)
  • health: Fix a bug where health checks failed for clients using legacy compression options (WithDecompressor or RPCDecompressor). (#​8765)
  • transport: Fix an issue where the HTTP/2 server could skip header size checks when terminating a stream early. (#​8769)

Performance Improvements

  • credentials/alts: Optimize read buffer alignment to reduce copies. (#​8791)
  • mem: Optimize pooling and creation of buffer objects. (#​8784)
  • transport: Reduce slice re-allocations by reserving slice capacity. (#​8797)

v1.78.0: Release 1.78.0

Compare Source

Behavior Changes
  • client: Reject target URLs containing unbracketed colons in the hostname in Go version 1.26+. (#​8716)
New Features
  • stats/otel: Add backend service label to wrr metrics as part of A89. (#​8737)
  • stats/otel: Add subchannel metrics (without the disconnection reason) to eventually replace the pickfirst metrics. (#​8738)
  • client: Wait for all pending goroutines to complete when closing a graceful switch balancer. (#​8746)
Bug Fixes
  • transport/client : Return status code Unknown on malformed grpc-status. (#​8735)
  • client: Add experimental.AcceptCompressors so callers can restrict the grpc-accept-encoding header advertised for a call. (#​8718)
  • xds: Fix a bug in StringMatcher where regexes would match incorrectly when ignore_case is set to true. (#​8723)
  • xds/resolver:
    • Drop previous route resources and report an error when no matching virtual host is found.
    • Only log LDS/RDS configuration errors following a successful update and retain the last valid resource to prevent transient failures. (#​8711)
  • client:
    • Change connectivity state to CONNECTING when creating the name resolver (as part of exiting IDLE).
    • Change connectivity state to TRANSIENT_FAILURE if name resolver creation fails (as part of exiting IDLE).
    • Change connectivity state to IDLE after idle timeout expires even when current state is TRANSIENT_FAILURE.
    • Fix a bug that resulted in OnFinish call option not being invoked for RPCs where stream creation failed. (#​8710)
  • xdsclient: Fix a race in the xdsClient that could lead to resource-not-found errors. (#​8627)
Performance Improvements
  • mem: Round up to nearest 4KiB for pool allocations larger than 1MiB. (#​8705)

v1.77.0: Release 1.77.0

Compare Source

API Changes

  • mem: Replace the Reader interface with a struct for better performance and maintainability. (#​8669)

Behavior Changes

  • balancer/pickfirst: Remove support for the old pick_first LB policy via the environment variable GRPC_EXPERIMENTAL_ENABLE_NEW_PICK_FIRST=false. The new pick_first has been the default since v1.71.0. (#​8672)

Bug Fixes

  • xdsclient: Fix a race condition in the ADS stream implementation that could result in resource-not-found errors, causing the gRPC client channel to move to TransientFailure. (#​8605)
  • client: Ignore HTTP status header for gRPC streams. (#​8548)
  • client: Set a read deadline when closing a transport to prevent it from blocking indefinitely on a broken connection. (#​8534)
  • client: Fix a bug where default port 443 was not automatically added to addresses without a specified port when sent to a proxy.
    • Setting environment variable GRPC_EXPERIMENTAL_ENABLE_DEFAULT_PORT_FOR_PROXY_TARGET=false disables this change; please file a bug if any

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

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

🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR was generated by Mend Renovate. View the repository job log.

@renovate

renovate Bot commented Aug 9, 2024

Copy link
Copy Markdown
Contributor Author

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 10 additional dependencies were updated

Details:

Package Change
google.golang.org/api v0.111.0 -> v0.114.0
cloud.google.com/go/compute v1.18.0 -> v1.19.1
github.com/golang/protobuf v1.5.2 -> v1.5.3
github.com/googleapis/gax-go/v2 v2.7.0 -> v2.7.1
golang.org/x/net v0.8.0 -> v0.9.0
golang.org/x/oauth2 v0.6.0 -> v0.7.0
golang.org/x/sys v0.6.0 -> v0.7.0
golang.org/x/text v0.8.0 -> v0.9.0
google.golang.org/genproto v0.0.0-20230306155012-7f2fa6fef1f4 -> v0.0.0-20230410155749-daa745c078e1
google.golang.org/protobuf v1.28.1 -> v1.30.0

@renovate

renovate Bot commented Dec 17, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 6 additional dependencies were updated
  • The go directive was updated for compatibility reasons

Details:

Package Change
go 1.19 -> 1.25.0
google.golang.org/api v0.111.0 -> v0.264.0
github.com/golang/protobuf v1.5.2 -> v1.5.4
github.com/google/uuid v1.3.0 -> v1.6.0
github.com/googleapis/enterprise-certificate-proxy v0.2.3 -> v0.3.11
github.com/googleapis/gax-go/v2 v2.7.0 -> v2.17.0
google.golang.org/protobuf v1.28.1 -> v1.36.11

@renovate
renovate Bot force-pushed the renovate/go-google.golang.org-grpc-vulnerability branch from f9da3af to dd701b3 Compare March 31, 2026 16:48
@renovate renovate Bot changed the title Update module google.golang.org/grpc to v1.56.3 [SECURITY] Update module google.golang.org/grpc to v1.79.3 [SECURITY] Mar 31, 2026
@renovate
renovate Bot force-pushed the renovate/go-google.golang.org-grpc-vulnerability branch from dd701b3 to 8554fee Compare July 25, 2026 19:28
@renovate renovate Bot changed the title Update module google.golang.org/grpc to v1.79.3 [SECURITY] Update module google.golang.org/grpc to v1.82.1 [SECURITY] Jul 25, 2026
@renovate
Update module google.golang.org/grpc to v1.83.1 [SECURITY]
428a7b1 
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate
renovate Bot force-pushed the renovate/go-google.golang.org-grpc-vulnerability branch from 8554fee to 428a7b1 Compare September 5, 2026 23:45
@renovate renovate Bot changed the title Update module google.golang.org/grpc to v1.82.1 [SECURITY] Update module google.golang.org/grpc to v1.83.1 [SECURITY] Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

type:security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants