CVE-2025-9708: 
C# vulnerability analysis and mitigation

CVE-2025-9708 is an improper certificate validation vulnerability in the Kubernetes C# client (NuGet package KubernetesClient) that allows a network-positioned attacker to perform man-in-the-middle (MitM) attacks against applications communicating with the Kubernetes API server. The flaw affects all versions of the Kubernetes C# client up to and including v17.0.13, with v17.0.14 being the first patched release. It was publicly disclosed on September 16, 2025, via the oss-security mailing list and the Kubernetes security announce group. The vulnerability carries a CVSS v3.1 base score of 6.8 (Medium) (GitHub Advisory, Kubernetes Issue, oss-security).

The root cause is classified as CWE-295 (Improper Certificate Validation). When the Kubernetes C# client is configured to use a custom Certificate Authority (CA) via the certificate-authority field in a kubeconfig file, the certificate validation logic accepts properly constructed certificates signed by any CA without correctly verifying the trust chain against the specified custom CA. This means an attacker who can intercept TLS traffic (e.g., via network positioning on an untrusted network) can present a forged certificate signed by a different, attacker-controlled CA and have it accepted by the client. Exploitation requires the victim application to be using a custom CA in its kubeconfig and for the attacker to be in a network position to intercept the TLS connection, making the attack complexity high and requiring some form of user/application interaction (GitHub Advisory, Kubernetes Issue).

Successful exploitation allows an attacker to intercept and manipulate TLS-encrypted communications between the Kubernetes C# client and the Kubernetes API server, compromising both confidentiality and integrity of those communications. An attacker could read sensitive API responses (including secrets, configuration data, and cluster state), inject malicious API responses to manipulate cluster behavior, or impersonate the API server entirely. Availability is not directly impacted, but the ability to manipulate API communications could enable further lateral movement within a Kubernetes environment (GitHub Advisory, oss-security).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is approximately 0.028% (9th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network-adjacent attacker capable of intercepting TLS traffic, which raises the practical bar for abuse (GitHub Advisory, Feedly).

1. Reconnaissance: Identify target applications using the Kubernetes C# client (KubernetesClient NuGet package, version ≤17.0.13) that connect to a Kubernetes API server with a custom CA certificate specified in their kubeconfig file.
2. Network Positioning: Gain a man-in-the-middle position on the network path between the vulnerable C# client and the Kubernetes API server (e.g., via ARP spoofing, rogue Wi-Fi access point, or compromised network infrastructure on an untrusted network segment).
3. Forge a Certificate: Generate a self-signed CA and issue a TLS certificate for the Kubernetes API server's hostname, signed by the attacker-controlled CA.
4. Intercept TLS Handshake: Present the forged certificate to the vulnerable C# client during the TLS handshake. Due to the improper trust chain validation, the client accepts the certificate despite it not being signed by the configured custom CA.
5. Intercept/Manipulate Traffic: Decrypt and read API communications (e.g., secrets, pod configurations), inject malicious API responses, or relay modified requests/responses between the client and the real API server to achieve API impersonation or data exfiltration (Kubernetes Issue, oss-security).

• Network: Unexpected TLS certificate presented by the Kubernetes API server endpoint that is not signed by the configured custom CA; unusual intermediate hosts appearing in network traces between the client and the API server.
• Logs: Client application logs showing successful TLS connections to the Kubernetes API server from unexpected IP addresses or with unexpected certificate fingerprints; log entries indicating connections over untrusted or unexpected network paths.
• Application Behavior: Unexpected API responses or errors that do not match expected cluster state; anomalous data returned from API calls that could indicate response tampering.
• Configuration Review: Presence of the certificate-authority field in kubeconfig files used by C# applications running KubernetesClient ≤17.0.13 on untrusted networks (Kubernetes Issue, oss-security).

The primary remediation is to upgrade the Kubernetes C# client (KubernetesClient NuGet package) to version v17.0.14 or later, which contains the fix for the improper trust chain validation. As a temporary workaround for environments that cannot immediately upgrade, administrators can move the custom CA certificates from the kubeconfig file into the system's trusted root certificate store — though this carries the risk of all system processes trusting that CA. Alternatively, disabling the custom CA in kubeconfig and adding the CA to the machine's trusted root store is also viable. Organizations should also review kubeconfig files for use of the certificate-authority field and ensure client connections occur only over trusted network segments (Kubernetes Issue, oss-security, GitHub Advisory).

The Kubernetes Security Response Committee disclosed the vulnerability via the official kubernetes-security-announce Google Group and the oss-security mailing list on September 16, 2025, coordinated by Rita Zhang, Boshi Lian, and Brendan Burns. The official Kubernetes social media accounts on X (Twitter) and Bluesky amplified the advisory shortly after disclosure. Security news outlets including SecurityOnline.info and GBHackers covered the vulnerability, and it was featured in the "Last Week in Kubernetes" digest for the week ending September 18, 2025. Community discussion on Reddit's CVEWatch subreddit listed it among the top trending CVEs for September 19, 2025 (Kubernetes Announce, oss-security).