[Release-4.18] OCPBUGS-80304: Update grpc-go to v1.71.3-sec.1 to fix CVE-2026-33186 #735
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -203,18 +203,19 @@ require ( | |
| go.mongodb.org/mongo-driver v1.14.0 // indirect | ||
| go.mozilla.org/pkcs7 v0.0.0-20210826202110-33d05740a352 // indirect | ||
| go.opencensus.io v0.24.0 // indirect | ||
| go.opentelemetry.io/auto/sdk v1.1.0 // indirect | ||
| go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.54.0 // indirect | ||
| go.opentelemetry.io/otel v1.34.0 // indirect | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.29.0 // indirect | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.27.0 // indirect | ||
| go.opentelemetry.io/otel/metric v1.34.0 // indirect | ||
| go.opentelemetry.io/otel/sdk v1.34.0 // indirect | ||
| go.opentelemetry.io/otel/trace v1.34.0 // indirect | ||
| go.opentelemetry.io/proto/otlp v1.3.1 // indirect | ||
| go.starlark.net v0.0.0-20230612165344-9532f5667272 // indirect | ||
| golang.org/x/crypto v0.32.0 // indirect | ||
|
There was a problem hiding this comment. 🧩 Analysis chain🌐 Web query:
💡 Result: For golang.org/x/crypto, the latest patched version as of 2026-05-25 is v0.52.0 (go.dev/pkglatest). [1] GO-2025-3487 affects golang.org/x/crypto. It was published Feb 26, 2025, and the affected versions are “before v0.35.0”; i.e., v0.35.0 is the first patched release for this specific issue. [2] So for a project currently using golang.org/x/crypto v0.32.0, it is affected by GO-2025-3487, and should be upgraded to at least v0.35.0 (preferably to the newest available: v0.52.0). [2][3][1] Citations:
Update golang.org/x/crypto v0.32.0 // indirect🧰 Tools🪛 OSV Scanner (2.3.8)[HIGH] 216-216: golang.org/x/crypto 0.32.0: Potential denial of service in golang.org/x/crypto (GO-2025-3487) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Potential denial of service in golang.org/x/crypto/ssh/agent (GO-2025-4116) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Unbounded memory consumption in golang.org/x/crypto/ssh (GO-2025-4134) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Malformed constraint may cause denial of service in golang.org/x/crypto/ssh/agent (GO-2025-4135) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking key constraints not enforced in golang.org/x/crypto/ssh/agent (GO-2026-5005) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking agent constraints dropped when forwarding keys in golang.org/x/crypto/ssh/agent (GO-2026-5006) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking byte arithmetic causes underflow and panic in golang.org/x/crypto/ssh (GO-2026-5013) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking bypass of certificate restrictions in golang.org/x/crypto/ssh (GO-2026-5014) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking server panic during CheckHostKey/Authenticate in golang.org/x/crypto/ssh (GO-2026-5015) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking memory leak when rejecting channels can lead to DoS in golang.org/x/crypto/ssh (GO-2026-5016) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking client can cause server deadlock on unexpected responses in golang.org/x/crypto/ssh (GO-2026-5017) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking pathological RSA/DSA parameters may cause DoS in golang.org/x/crypto/ssh (GO-2026-5018) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking bypass of FIDO/U2F security keys physical interaction in golang.org/x/crypto/ssh (GO-2026-5019) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking infinite loop on large channel writes in golang.org/x/crypto/ssh (GO-2026-5020) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking auth bypass via unenforced (GO-2026-5021) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking VerifiedPublicKeyCallback permissions skip enforcement in golang.org/x/crypto/ssh (GO-2026-5023) [HIGH] 216-216: golang.org/x/crypto 0.32.0: Invoking pathological inputs can lead to client panic in golang.org/x/crypto/ssh/agent (GO-2026-5033) [HIGH] 216-216: golang.org/x/crypto 0.32.0: golang.org/x/crypto/ssh/agent vulnerable to panic if message is malformed due to out of bounds read [HIGH] 216-216: golang.org/x/crypto 0.32.0: golang.org/x/crypto Vulnerable to Denial of Service (DoS) via Slow or Incomplete Key Exchange [HIGH] 216-216: golang.org/x/crypto 0.32.0: golang.org/x/crypto/ssh allows an attacker to cause unbounded memory consumption 🤖 Prompt for AI Agents |
||
| golang.org/x/net v0.34.0 // indirect | ||
| golang.org/x/oauth2 v0.25.0 // indirect | ||
|
There was a problem hiding this comment. 🧩 Analysis chain🌐 Web query:
💡 Result: For golang.org/x/oauth2 version v0.25.0, the relevant memory-consumption vulnerability is documented in Go vulnerability record GO-2025-3488 (CVE-2025-22868): an attacker can send a malicious malformed token that causes unexpected memory consumption during parsing, i.e., a denial-of-service style issue [1][2]. Affected versions: the Go vulnerability entry states it affects golang.org/x/oauth2 before v0.27.0 (introduced fixed at 0.27.0) [1][3][2]. Therefore, v0.25.0 is within the affected range [1]. Fix / remediation: the Go security announcement for this issue says they tagged v0.27.0 to address the security issue in the golang.org/x/oauth2/jws package, with version v0.27.0 fixing the problem [2]. (OSV/Go vuln pages also show the fix at 0.27.0) [1][3]. Memory consumption details (what the issue is): the Go vuln entry describes “unexpected memory to be consumed during parsing” when parsing a malformed token [1]. The pkg.go.dev vuln entry additionally summarizes it as “Unexpected memory consumption during token parsing in golang.org/x/oauth2” [3]. Citations:
🌐 Web query:
💡 Result: For GHSA-6v2p-p543-phr9 affecting golang.org/x/oauth2, the fixed version is 0.27.0, and the affected range is versions from 0 up to (but not including) 0.27.0 (i.e., fixed starting at 0.27.0). [1][2][3] So, to remediate on today’s date (2026-05-25), upgrade golang.org/x/oauth2 to version 0.27.0 or later. [1][2][3] Citations:
Update
Upgrade golang.org/x/oauth2 v0.25.0 // indirect🧰 Tools🪛 OSV Scanner (2.3.8)[HIGH] 218-218: golang.org/x/oauth2 0.25.0: Unexpected memory consumption during token parsing in golang.org/x/oauth2 (GO-2025-3488) [HIGH] 218-218: golang.org/x/oauth2 0.25.0: golang.org/x/oauth2 Improper Validation of Syntactic Correctness of Input vulnerability 🤖 Prompt for AI Agents |
||
| golang.org/x/sync v0.10.0 // indirect | ||
| golang.org/x/sys v0.29.0 // indirect | ||
| golang.org/x/term v0.28.0 // indirect | ||
|
|
@@ -223,10 +224,10 @@ require ( | |
| golang.org/x/tools v0.26.0 // indirect | ||
| gomodules.xyz/jsonpatch/v2 v2.4.0 // indirect | ||
| google.golang.org/genproto v0.0.0-20240311173647-c811ad7063a7 // indirect | ||
| google.golang.org/genproto/googleapis/api v0.0.0-20250106144421-5f5ef82da422 // indirect | ||
| google.golang.org/genproto/googleapis/rpc v0.0.0-20250115164207-1a7da9e5054f // indirect | ||
| google.golang.org/grpc v1.70.0 // indirect | ||
| google.golang.org/protobuf v1.36.4 // indirect | ||
|
Comment on lines
+227
to
+230
There was a problem hiding this comment. 🧩 Analysis chain🌐 Web query:
💡 Result: CVE-2026-33186 is a gRPC-Go authorization bypass caused by improper validation of the HTTP/2:path pseudo-header (missing the mandatory leading slash). When a request is sent with:path like “Service/Method” instead of “/Service/Method”, gRPC-Go routes it correctly, but path-based authorization interceptors (including google.golang.org/grpc/authz) evaluate the raw non-canonical path. As a result, “deny” rules that target canonical paths (starting with “/”) fail to match, which can allow the request to proceed if a fallback “allow” policy exists [1][2]. Affected versions / fixed version: gRPC-Go versions prior to v1.79.3 are vulnerable; v1.79.3 contains the fix [1][3]. Technical root cause (as described in sources): gRPC-Go’s server transport/routing layer was overly lenient about:path formatting, allowing requests where the:path omitted the leading slash to reach authorization logic using the non-canonical value [1][2]. What the fix does: the fix rejects requests whose:path does not start with “/” by immediately returning a gRPC error (codes.Unimplemented), preventing malformed paths from reaching authorization interceptors or handlers [1][4]. The grpc-go PR notes this as “strict path checking” in Server.handleStream and mentions a temporary opt-out env var GRPC_GO_EXPERIMENTAL_DISABLE_STRICT_PATH_CHECKING=true [4]. Who is impacted (conditions for exploitation): gRPC-Go servers that use path-based authorization interceptors (including the official authz RBAC) and have security policies with specific “deny” rules for canonical paths, but permissive fallback behavior (e.g., a fallback allow) [1]. Exploitation requires an attacker that can send raw HTTP/2 frames with malformed:path headers directly to the gRPC server (no credentials/prior state is implied in NVD-style description) [1]. Practical mitigation: 1) Upgrade to grpc-go / google.golang.org/grpc v1.79.3 or later [1]. 2) If upgrading isn’t immediately possible, apply mitigations mentioned in NVD: use a validating interceptor (recommended), normalize at the infrastructure layer, and/or harden policy [1]. Examples from downstream ecosystems: Traefik advisory indicates the fix propagates by bumping its dependency to gRPC-Go versions containing the patch; it lists affected Traefik versions and patched Traefik versions (v2.11.42, v3.6.12, v3.7.0-ea.3) [5]. Citations:
🏁 Script executed: #!/bin/bash
# Verify the openshift-sustaining grpc-go security patch version exists
echo "Checking if github.com/openshift-sustaining/grpc-go v1.71.3-sec.1 exists..."
go list -m -versions github.com/openshift-sustaining/grpc-go 2>&1 | head -20
# Check the CVE advisory using GitHub CLI
echo -e "\nChecking for gRPC security advisories..."
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "google.golang.org/grpc") {
nodes {
advisory {
summary
severity
publishedAt
identifiers {
type
value
}
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: openshift/operator-framework-operator-controller Length of output: 1877 CVE-2026-33186 is fixed in gRPC-Go 1.79.3; ensure the fork/tag you replace to actually includes that patch
🤖 Prompt for AI Agents |
||
| gopkg.in/evanphx/json-patch.v4 v4.12.0 // indirect | ||
| gopkg.in/inf.v0 v0.9.1 // indirect | ||
| gopkg.in/warnings.v0 v0.1.2 // indirect | ||
|
|
@@ -243,3 +244,5 @@ require ( | |
| ) | ||
|
|
||
| replace github.com/operator-framework/catalogd => github.com/openshift/operator-framework-catalogd v0.0.0-20241115041750-a02152ea36f4 | ||
|
|
||
| replace google.golang.org/grpc => github.com/openshift-sustaining/grpc-go v1.71.3-sec.1 | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
go.opentelemetry.io/otel/sdk 1.34.0 vulnerability PATH hijacking GO-2026-4394💡 Result:
GO-2026-4394 describes an OpenTelemetry Go SDK vulnerability where local PATH hijacking can lead to arbitrary code execution (ACE). 1) What’s affected - Vulnerable module: go.opentelemetry.io/otel/sdk. - OS/file: the vulnerability is about PATH hijacking when the SDK executes system commands during resource detection (host ID collection). An advisory example describes macOS/Darwin “ioreg” being executed via PATH lookup, where a locally set PATH can cause execution of a attacker-controlled binary instead [1]. 2) Why it’s vulnerable (PATH hijacking / untrusted search path) - The issue class is “Untrusted Search Path” (CWE-426) where commands are executed using a search path rather than an absolute path, so a malicious executable earlier in PATH can be invoked [1]. - The OpenTelemetry advisories explain the exploit requires local ability to modify PATH so that the SDK’s command resolution picks the attacker’s binary [1]. 3) Range in the vulnerability database - OSV’s entry for GO-2026-4394 states the OpenTelemetry Go SDK is vulnerable from 1.21.0 (introduced) until 1.40.0 (fixed) [2]. - This means go.opentelemetry.io/otel/sdk v1.34.0 is within the vulnerable range (>= 1.21.0 and < 1.40.0) [2][3]. 4) Fixed version / remediation - Upgrade to go.opentelemetry.io/otel/sdk v1.40.0 or later; OSV lists 1.40.0 as the fixed version for GO-2026-4394 [2]. - The upstream advisory for the related PATH-hijacking issue also states it is patched in the release that shipped v1.40.0 [1]. 5) Practical mitigation if you can’t upgrade immediately - Prevent local attackers from influencing PATH (or run in an environment where PATH cannot be modified by untrusted users), because the core condition is the ability to locally modify PATH so the SDK executes an attacker-controlled binary [1]. Note on naming: the OpenTelemetry repo has multiple advisories around PATH hijacking; the one that explicitly references ioreg on macOS/Darwin is GHSA-9h8m-3fm2-qjrq (CVE-2026-24051), and it aligns with the same overall class and fix timeline that OSV captures under GO-2026-4394 [2][1].
Citations:
Bump
go.opentelemetry.io/otel/sdkfromv1.34.0to a patched release (v1.40.0+) to fix PATH-hijacking arbitrary code execution.go.opentelemetry.io/otel/sdk v1.34.0is within the vulnerable range forGO-2026-4394/GHSA-9h8m-3fm2-qjrq(patched inv1.40.0).GHSA-hfvc-g4fc-pqhxisn’t established from the available evidence; still please ensure the upgrade covers that advisory as well.🧰 Tools
🪛 OSV Scanner (2.3.8)
[HIGH] 212-212: go.opentelemetry.io/otel/sdk 1.34.0: OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking in go.opentelemetry.io/otel/sdk
(GO-2026-4394)
[HIGH] 212-212: go.opentelemetry.io/otel/sdk 1.34.0: OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking
(GHSA-9h8m-3fm2-qjrq)
[HIGH] 212-212: go.opentelemetry.io/otel/sdk 1.34.0: opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking
(GHSA-hfvc-g4fc-pqhx)
🤖 Prompt for AI Agents