Bump google.golang.org/grpc from v1.72.1 to v1.79.3

[shubhi-gupta5]

What this PR does:

Which issue(s) this PR fixes:
Fixes #

Checklist

• Changes manually tested
• Automated Tests added/updated
• Documentation added/updated
• CHANGELOG.md updated (not required for documentation PRs)
• CLA Signed: DataStax CLA

[github-actions]

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

[burmanm]

This is indirect dependency coming from another package. We don't typically update these manually as any update to the real dependency would override this change and also might potentially break compatibility. Is there a real reason to update it?

[shubhi-gupta5]

This is indirect dependency coming from another package. We don't typically update these manually as any update to the real dependency would override this change and also might potentially break compatibility. Is there a real reason to update it?

@burmanm Thank you for the review! You're absolutely right that this is an indirect dependency. The dependency chain shows that google.golang.org/grpc@v1.72.1 is being pulled in by several Kubernetes packages:

• k8s.io/apiserver@v0.34.3
• k8s.io/component-base@v0.34.3
• sigs.k8s.io/controller-runtime@v0.22.5

However, I'm proposing this manual upgrade due to CVE-2026-33186, which is a Critical severity security vulnerability in google.golang.org/grpc versions below v1.79.3.

What would be the preferred approach for handling critical CVEs in indirect dependencies in this project?

[burmanm]

That would be those upstream projects. The vuln is in grpc/authz, but I don't see at least controller-runtime using it at all and none of the preconditions are met.

Kubernetes seems to ship 1.72.2 even in 1.35.4 (released 5 days ago) and have only updated in their main branch, so I'm not sure if they intend to update at all for any active releases.

[shubhi-gupta5]

That would be those upstream projects. The vuln is in grpc/authz, but I don't see at least controller-runtime using it at all and none of the preconditions are met.

Kubernetes seems to ship 1.72.2 even in 1.35.4 (released 5 days ago) and have only updated in their main branch, so I'm not sure if they intend to update at all for any active releases.

@burmanm Thanks for the clarification!
Should I consider this as a false positive for the time being?

[burmanm]

For now, yes. If we later have to fix it for the CVE scanners, then the correct approach (forgot to mention this) is to set replace directive. That prevents any other updates from downgrading it back to the old version. But those always require maintenance later as they have to be manually also removed so I hope to avoid them.