Security: CVE Fix Request for kube-rbac-proxy Go Binary

[rohandhamapurkar]

Summary

Our security scan has flagged two vulnerabilities in the Go stdlib package used by usr/local/bin/kube-rbac-proxy.
The current installed version is Go v1.25.4, which contains known HIGH and MEDIUM severity CVEs.
A fix is available in Go 1.24.11 or 1.25.5.

---

📌 Affected Component

• Binary: usr/local/bin/kube-rbac-proxy
• Category: Go binary (lang-pkgs)
• Go stdlib version: v1.25.4

---

⚠️ Vulnerabilities Detected

1. CVE-2025-61729

• Severity: HIGH
• Package: stdlib
• Installed version: v1.25.4
• Fixed version: 1.24.11, 1.25.5
• CVSS v3: 7.5
• Status: WARNING

2. CVE-2025-61727

• Severity: MEDIUM
• Package: stdlib
• Installed version: v1.25.4
• Fixed version: 1.24.11, 1.25.5
• CVSS v3: 6.5
• Status: WARNING

---

🛠 Required Action

Please update the Go toolchain used to build kube-rbac-proxy to a secure version:

✔ Recommended fix:

Upgrade to Go 1.25.5 (patch release resolving both CVEs).

This will require:

• Updating the Go version in the build environment
• Rebuilding the kube-rbac-proxy binary
• Publishing a patched image/version
• Validating functionality and compatibility impacts

[ibihim]

Thanks for highlighting these CVEs.

I ran govulncheck and it does show these functions are reachable:

$ govulncheck ./...
Vulnerability #1: GO-2025-4175
    Found in: crypto/x509@go1.25.4
    Fixed in: crypto/x509@go1.25.5
    Example traces found:
      #1: for function crypto/x509.Certificate.Verify
        DelegatingAuthenticator.AuthenticateRequest
        → Verifier.AuthenticateRequest
        → Certificate.Verify

Vulnerability #2: GO-2025-4155
    Found in: crypto/x509@go1.25.4
    Fixed in: crypto/x509@go1.25.5
    Example traces found:
      #1: for function crypto/x509.Certificate.Verify
        (same as above)
      #2: for function crypto/x509.Certificate.VerifyHostname
        main → cli.Run → ... → tls.Conn.clientHandshake
        → Certificate.VerifyHostname

However, reachability ≠ exploitability. Looking at the actual call sites:

CVE-2025-61729 (DoS in HostnameError.Error()):

• Client certificate path: Certificate.Verify() is called on client certs, but VerifyHostname() is not — there's no "expected hostname" to verify against for client auth. The DoS only triggers when hostname verification fails.
• Upstream TLS path: VerifyHostname() is called when connecting to the upstream, but the upstream URL is admin-configured via --upstream. An attacker cannot inject a malicious server.

CVE-2025-61727 (Wildcard SAN exclusion bypass):

• This requires a malicious CA chain with excluded subdomain constraints. The CA bundle is admin-configured — an attacker cannot inject a malicious CA.

We'll bump the Go version in an upcoming release, but don't see this as urgent given the above. If you can describe a concrete attack scenario where an attacker controls the certificate presented to these code paths, let us know.

[rohandhamapurkar]

Thanks for digging into this so thoroughly that breakdown makes sense, and I agree “reachable” from govulncheck isn’t automatically “exploitable”.

Based on your analysis, I also don’t see a practical remote exploit path in the default / intended threat model:

• For CVE-2025-61729: the client-cert auth flow only hits Certificate.Verify() and doesn’t do VerifyHostname(), so the quadratic HostnameError.Error() path shouldn’t be triggerable via client auth. And for upstream TLS, VerifyHostname() is only exercised against the admin-configured --upstream target, so there isn’t an attacker-controlled cert presentation there unless the upstream itself is untrusted/compromised or traffic is being intercepted.

• For CVE-2025-61727: if the CA bundle is admin-provided and treated as trusted, an attacker can’t realistically introduce a malicious constrained chain without already having a foothold (misconfiguration / compromised config management / etc.).

So I’m aligned that this isn’t urgent from an exploitability standpoint.

That said, the main pain point on our side is operational: scanners still flag the published image as vulnerable because it embeds Go 1.25.4’s stdlib, and we have “block on HIGH” policies. Even if it’s low-risk, it becomes a release-gating issue for downstream consumers.

No further action needed on my side if you’ve already got this planned just sharing why some of us are pushing for a rebuild even with low exploitability.