[CVE] bump oras-go to v2.6.2 and grpc to v1.82.1 (release-v1.40)

[pasanw]

✅ 3 High CVEs removed (oras ×2, grpc ×1) · 3 remain (containerd — VEX, deferred to hold k8s 1.35)

Indirect Go-dependency bumps only — no operator code changes and no Kubernetes-version change. This branch (release-v1.40, Calico Enterprise v3.22.7) is deliberately kept on k8s 1.35 to stay aligned with the calico-private core; see FYI.

Core version changes

None. Helm (v3.20.2) and the k8s.io/* client (v0.35.7) are deliberately unchanged. Bumping Helm to drop the transitive containerd dependency would drag k8s to 1.36 and diverge this branch's Kubernetes minor from the calico-private core (k8s 1.35). See the containerd row and FYI.

Package version changes

Name	Version bump	Breaking changes	Notes
oras.land/oras-go/v2	2.6.0 → 2.6.2	None (patch)	Indirect dep. Clears both oras path-traversal/credential-leak CVEs. Carries an advisory-naming // indirect; pinned: … comment so a future go mod tidy cannot silently revert it.
google.golang.org/grpc	1.80.0 → 1.82.1	None (patch)	Indirect dep. Clears GHSA-hrxh-6v49-42gf. Advisory-naming comment retained for the same reason.

CVEs resolved

ID	Severity	Images verified with fix	Verification methodology	Notes
CVE-2026-50151	High	operator	ISS full scan (raw) — absent	oras-go 2.6.2 (blob-upload cross-host credential leak).
CVE-2026-50163	High	operator	ISS full scan (raw) — absent	oras-go 2.6.2 (hardlink path traversal). The scanner's fixed_version column read No fix available, but the advisory text itself, OSV, and the GitHub Advisory DB all record fixed = 2.6.2. An earlier iteration of this PR trusted the stale column and stopped at 2.6.1 — corrected here.
GHSA-hrxh-6v49-42gf (GO-2026-6061)	High	operator	ISS full scan (raw) — absent	grpc 1.82.1.

CVEs not resolved

ID	Severity	Why (full accounting)	Next step
CVE-2026-50195, CVE-2026-53492, CVE-2026-53489 (containerd 1.7.33)	2 Critical (CVE-2026-50195 CVSS 9.9, CVE-2026-53492 9.6) + 1 High (CVE-2026-53489)	containerd is not a direct dependency of the operator — it is pulled in transitively through Helm, and the operator neither imports nor invokes it. There is no in-line fix to move to: containerd 1.7.33 is the current 1.7.x release, and all three CVEs are fixed only in the 2.1.9 / 2.2.5 / 2.3.2 lines — there is no 1.7.x backport (confirmed against OSV; containerd 1.7.34 does not carry these fixes either). The one route that removes the vulnerable code entirely is to bump Helm to v3.21.3, which drops the transitive containerd dependency from the module graph — but Helm reaches k8s v0.36 at v3.21.2, so every containerd-free Helm is already on k8s 1.36. Taking that route would move this branch to k8s 1.36, diverging its Kubernetes minor from the calico-private core (which stays on k8s 1.35 this round). That divergence is exactly what this PR is scoped to avoid, so the containerd removal is deliberately deferred on the v1.40 line. (master and release-v1.43 — already on k8s 1.36 — take the Helm route in #5100 / #5101.) The raw scan shows more than three crit/high rows for containerd because twistcli and grype each list every finding and grype rates two of them critical where twistcli rates them medium/high; de-aliased, there are exactly these 3 distinct CVEs.	VEX / allowlist all three as no-fix + deferred. Re-evaluate when the v1.40 line takes a k8s-1.36 uplift (which brings a containerd-free Helm) or when a patched containerd 1.7.x is published.

FYI

• Option B (k8s-1.35 hold). master / release-v1.43 cleared containerd by bumping Helm to v3.21.3 (which drags k8s → 1.36); this branch deliberately does not, to keep the operator's k8s minor aligned with the calico-private core. That is the whole reason containerd stays VEX'd rather than fixed here.
• Supersedes the autoclosed Renovate security PRs chore(deps): update module google.golang.org/grpc to v1.82.1 [security] (release-v1.40) - autoclosed #5092 (grpc) and chore(deps): update module oras.land/oras-go/v2 to v2.6.1 [security] (release-v1.40) - autoclosed #5011 (oras 2.6.1). Renovate keys vulnerability alerts off the default branch, so a release branch's security PR autocloses the moment master is fixed — the branch's residual exposure then goes invisible to automation, part of why this lingered.
• Fix-forward hole. release-v1.41 (grpc 1.75.1 + oras 2.6.0) and release-v1.42 (grpc 1.80.0 + oras 2.6.0) are newer than v1.40 but still vulnerable — a customer upgrading past this line reacquires the CVEs. Companion PRs to those branches should follow.
• enterprise label removed — a go.mod bump ships to every install (OSS and Enterprise), and the sibling security PRs are unlabelled.
• Correction of record: the earlier iteration stopped at oras 2.6.1 and stated "2.6.2 is not the fix" for CVE-2026-50163; that was wrong (OSV/GHSA/advisory text all say fixed = 2.6.2) and is corrected.

Release Note

Bumped oras-go to v2.6.2 and grpc to v1.82.1 to remediate oras-go CVE-2026-50151/CVE-2026-50163 and GHSA-hrxh-6v49-42gf. containerd advisories remain deferred (no containerd fix exists; removal would require a k8s-1.36 uplift not taken on this line).

For PR reviewers

Suggested labels: kind/bug, release-note-required, docs-not-required (no enterprise).

[electricjesus]

looks solid. I checked the version claims and the containerd call, and they all hold up. two follow-up notes:

release-v1.42 is already on k8s.io/client-go v0.36.3, but still on helm.sh/helm/v3 v3.20.2. So the k8s reason for holding containerd back doesn't apply there. It could take 3.21.3 today, same as master and v1.43. Might be worth naming it in the FYI next to them..

other one is the VEX next-step. The scan lists these under their GO-* and GHSA-* ids too, and the allowlist matches on the id. So all three forms need to go in, or the rows stay:

• CVE-2026-50195 / GO-2026-5338 / GHSA-cvxm-645q-p574
• CVE-2026-53492 / GO-2026-5064 / GHSA-33vj-92qq-66hc
• CVE-2026-53489 / GO-2026-5622 / GHSA-rgh6-rfwx-v388

[electricjesus]

checked this one myself since you called out the correction. OSV backs you up. 2.6.0 matches five advisories, 2.6.1 still matches CVE-2026-50163, and 2.6.2 comes back clean. So 2.6.2 is right, and that No fix available column is just stale.

Worth knowing the same bump clears three more that 2.6.1 had already fixed: CVE-2026-50162, CVE-2026-48978, GO-2026-5884. All moderate or low, so they sit under the bar. Just more than the two you credited.