Kubernetes C# Client Flaw Exposes API Server to MiTM Attacks

A recently disclosed vulnerability in the Kubernetes C# client library allows attackers to carry out man-in-the-middle (MiTM) attacks against the API server.

The flaw stems from improper certificate validation when using custom certificate authorities (CAs).

As organizations increasingly rely on Kubernetes for container orchestration, this weakness could enable interception or alteration of critical control-plane traffic, potentially compromising cluster integrity and confidentiality.

Overview of the Vulnerability

The root cause lies in the client’s handling of custom CA certificates specified in the kubeconfig file.

Instead of validating the full trust chain, the library accepts any properly structured certificate signed by the custom CA without verifying intermediate certificates or revocation status.

An attacker who can intercept TLS traffic, such as on a public network or a compromised router, can present a forged certificate that the client will accept.

Once trusted, the attacker can decrypt and re-encrypt traffic between the application and the Kubernetes API server, enabling credential theft, command injection, or manipulation of API requests and responses.

All versions of the Kubernetes C# client prior to v17.0.14 are vulnerable when configured with a custom CA in the kubeconfig file.

Systems using this client over untrusted networks such as remote management consoles, external CI/CD pipelines, or cloud-based development workstations face the highest risk.

Even internal environments may be at risk if network segmentation is inadequate or if attackers can pivot laterally.

The vulnerability carries a CVSS v3.1 score of 6.8 (Medium), reflecting network attack vector, high impact on confidentiality and integrity, but requiring minimal privileges and some user interaction.

To address the vulnerability, upgrade the Kubernetes C# client to version 17.0.14 or later as soon as possible.

This release corrects the certificate validation logic to enforce full chain verification and rejection of untrusted certificates.

As an interim measure, move custom CA certificates into the operating system’s trusted root store and disable the client’s custom CA mode.

Note that this approach will trust the CA system-wide, which may introduce additional risk if other applications use the same CA.

 Administrators should audit kubeconfig files for the certificate-authority field and review client logs for unexpected TLS errors or warnings.

The flaw was reported by @elliott-beach and fixed through coordinated efforts by Boshi Lian, Brendan Burns, and Rita Zhang, ensuring the client properly enforces trust chain validation in custom CA scenarios.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.