CVE-2026-105223 in kubernetes-client
Summary
by MITRE • 10/05/2026
maclof kubernetes-client 0.17.0 before 0.32.0 disables TLS certificate verification in parseKubeconfig() and parseKubeconfigFile() when a kubeconfig lacks certificate-authority-data, ignoring insecure-skip-tls-verify. On-path attackers can impersonate the Kubernetes API server to capture Bearer tokens or Basic credentials and tamper with WebSocket or REST API traffic.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability in maclof kubernetes-client versions prior to 0.32.0 represents a critical misconfiguration within the library's kubeconfig parsing logic, specifically affecting the parseKubeconfig() and parseKubeconfigFile() functions. This flaw stems from an incorrect implementation of TLS certificate verification during the initialization phase when connecting to a Kubernetes cluster. Under normal operational circumstances, clients are expected to validate the server's identity by verifying its X.509 certificate against trusted Certificate Authorities or using specific client-side certificates. However, in this affected code path, if the provided kubeconfig file does not explicitly contain data for a certificate-authority-data field, the library erroneously disables TLS verification entirely. This behavior is particularly dangerous because it occurs regardless of whether the insecure-skip-tls-verify flag has been set to false or omitted, effectively bypassing security controls that administrators might have intended to enforce through standard configuration practices.
From a technical perspective, this issue aligns with CWE-295 Improper Certificate Validation and CWE-319 Cleartext Transmission of Sensitive Information. The root cause lies in the conditional logic used to determine trust anchors for HTTPS connections. By treating the absence of certificate-authority-data as an implicit signal to skip verification rather than raising a validation error or falling back to system defaults, the library creates a silent failure mode. This means that applications relying on this client library may appear to be functioning correctly while actually transmitting data over unencrypted and unauthenticated channels if the kubeconfig is not meticulously configured with explicit CA data. The flaw ignores the broader context of security policies defined in the configuration file, leading to a significant degradation of transport layer security integrity.
The operational impact of this vulnerability is severe due to its susceptibility to Man-in-the-Middle attacks. An attacker positioned on the network path between the client and the Kubernetes API server can exploit this lack of verification to impersonate the legitimate API endpoint. Since TLS handshake validation is skipped, the attacker can present a self-signed or forged certificate that the client will accept without question. Once the connection is established under false pretenses, the attacker gains the ability to intercept sensitive traffic. This includes capturing Bearer tokens used for authentication and authorization within the cluster, as well as Basic credentials if they are transmitted in any form. Furthermore, because Kubernetes relies heavily on WebSocket connections for features like exec sessions and port forwarding, an active attacker can also tamper with these streams, potentially injecting malicious commands or exfiltrating data from running pods without detection by standard security monitoring tools that rely on TLS integrity checks.
This vulnerability maps directly to the MITRE ATT&CK technique T1078 Valid Accounts, as it facilitates unauthorized access through credential theft, and T1557 Adversary-in-the-Middle, which describes the interception of communications between two parties who believe they are directly communicating with each other. The ability to capture Bearer tokens is particularly concerning because these tokens often grant elevated privileges within the Kubernetes RBAC system, potentially allowing lateral movement across namespaces or clusters. Additionally, tampering with REST API traffic could lead to data integrity violations where configuration changes or deployment updates are altered in transit, compromising the reliability and security of the entire container orchestration environment.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary solution is to upgrade the maclof kubernetes-client library to version 0.32.0 or later, where this parsing logic has been corrected to properly enforce certificate validation even when CA data is missing from specific fields, ensuring that connections fail securely rather than falling back to an insecure state. For environments unable to update immediately, administrators should ensure that all kubeconfig files explicitly include valid certificate-authority-data entries and avoid relying on implicit behaviors for security decisions. Furthermore, organizations should implement network-level controls such as mutual TLS (mTLS) at the infrastructure layer or use service meshes like Istio to enforce encryption and authentication independent of application-layer configurations. Regular auditing of client-side libraries against known vulnerability databases is also essential to prevent similar misconfigurations from impacting production workloads.