Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain on-path network position
-
DeliveryImpersonate Kubernetes API server with forged TLS cert
-
ExploitClient skips verification (no CA data)
-
ExecutionCapture Bearer/Basic credentials
-
ImpactTamper with REST/WebSocket API traffic
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Exploitation requires three concrete conditions. (1) The application must load a kubeconfig via parseKubeconfig() or parseKubeconfigFile() that LACKS certificate-authority-data while pointing at an https:// server - in that case vulnerable versions set verify off and ignore the insecure-skip-tls-verify flag entirely. (2) The affected version must be in range 0.17.0 through 0.31.x (fixed in 0.32.0). (3) The attacker must already occupy an on-path/man-in-the-middle position between the client and the Kubernetes API server (the AT:P attack requirement), which is the primary limiting factor - this is not remotely exploitable without traffic interception. Deployments that supply certificate-authority-data in their kubeconfig are not affected, which further limits real-world exposure. |
| Impact | This is a genuine but conditional MITM/transport-security flaw (CWE-295), not an overrated high-CVSS issue, though its real-world urgency is lower than the 9.1 score alone suggests. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) is internally consistent with the description: unauthenticated from the attacker's side (PR:N) but gated by two non-trivial preconditions - high attack complexity (AC:H) and a present attack requirement (AT:P), reflecting that the attacker must already hold an on-path/man-in-the-middle position between the PHP client and the Kubernetes API server. The impact pairing is well-justified: high confidentiality (capture of Bearer tokens / Basic credentials) and high integrity (tampering with REST and WebSocket traffic), with no availability impact (VA:N), matching the committed fix which re-enables TLS verification by default. No EPSS score, CISA KEV listing, or public POC is present in the supplied data, and the source-code evidence shows only a bug fix plus unrelated refactors - no weaponized exploit. The signals therefore align rather than conflict: a legitimately severe credential-exposure bug whose exploitation is constrained to adversaries who can already intercept traffic, making it a priority for operators who use this library over untrusted networks rather than an internet-wide mass-exploitation threat. |
| Exploit ScenarioDerived | A PHP application uses maclof/kubernetes-client (0.17.0-0.31.x) with a kubeconfig that omits certificate-authority-data and points at an https API server, causing the client to silently skip TLS verification. An attacker positioned on the network path (e.g. shared/untrusted LAN, compromised proxy, or rogue DNS) presents a forged certificate for the API server, captures the client's Bearer token or Basic credentials, and then relays or alters REST/WebSocket requests to the real cluster. No public exploit code is identified at time of analysis, so exploitation requires the attacker to build their own interception setup. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
TLS certificate verification is silently disabled in the PHP library maclof/kubernetes-client versions 0.17.0 through 0.31.x whenever a loaded kubeconfig omits certificate-authority-data but points at an https:// API server; the library's parseKubeconfig() and parseKubeconfigFile() helpers then ignore the user's insecure-skip-tls-verify setting and turn verification off. This only matters to an attacker who already holds an on-path/man-in-the-middle position between the client and the Kubernetes API server, from which they can impersonate the API server, harvest Bearer tokens or Basic credentials, and tamper with REST or WebSocket traffic. Exploitation is conditional rather than opportunistic - there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV does not list it); unaffected deployments are those whose kubeconfig supplies certificate-authority-data. The 9.1 CVSS score reflects the high confidentiality and integrity impact, but real-world urgency is lower than that number suggests because of the attack-position requirement and the fix available in 0.32.0.
RemediationAI
Upgrade to maclof/kubernetes-client 0.32.0 or later (for example, composer require maclof/kubernetes-client:^0.32.0), which is the vendor-released patch; the fix is the commit https://github.com/maclof/kubernetes-client/commit/924c0b935fa538ed6b4b0948127609e99d0e6f34 and the tagged release is https://github.com/maclof/kubernetes-client/releases/tag/0.32.0, with details in issue https://github.com/maclof/kubernetes-client/issues/135 and the VulnCheck advisory. If upgrading immediately is not possible, the most effective compensating control is to always include a valid certificate-authority-data block (or the CA bundle path) in every kubeconfig that points at an https:// API server, because that keeps the client out of the flawed branch - the trade-off is that you must maintain and distribute the correct CA material and rotate it with the cluster, and note that adding insecure-skip-tls-verify: false does NOT help on vulnerable versions. Alternatively, construct the client explicitly with a Guzzle 'verify' option pointing at a trusted CA bundle instead of relying on parseKubeconfig defaults, which requires code changes at every client instantiation site. Where neither is feasible, reduce blast radius by treating all traffic to the API server as attacker-inspectable: restrict the credentials reachable from the client to least-privilege, short-lived tokens, enforce network-layer protections (mTLS through a service mesh or TLS-terminating proxy that validates the API server certificate on the client's behalf), and audit for any historical exposure - if a kubeconfig without CA data has been used against an https:// server over an untrusted network, assume the Bearer token or Basic credentials may have been captured and rotate them.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
maclof/kubernetes-client is a PHP client for the Kubernetes API that builds a Guzzle HTTP client from a kubeconfig file. The root cause is CWE-295 (Improper Certificate Validation): in the affected versions, the branch of src/Client.php that handles an https:// master URL deferred to Kubernetes' conventional 'insecure-skip-tls-verify' semantics but effectively set the Guzzle 'verify' option to false whenever no certificate-authority-data was present, so the explicit insecure-skip-tls-verify flag was never honored and no CA bundle was loaded. Because kubeconfigs commonly omit certificate-authority-data when relying on a public/system CA trust store, this silently downgraded an otherwise verified TLS session to an unauthenticated one, allowing an on-path attacker to present any certificate and terminate the TLS session themselves. The fix commit 924c0b935fa538ed6b4b0948127609e99d0e6f34 reorders the logic so that the https branch sets $options['verify'] = true by default and only disables verification when the cluster stanza explicitly sets 'insecure-skip-tls-verify' to boolean true; the added tests (testKubeconfigWithoutCaKeepsTlsVerificationEnabled, testKubeconfigCanExplicitlyDisableTlsVerification) confirm the intended behavior. Once TLS is unauthenticated, everything the client sends is exposed - the Authorization header carrying the Kubernetes service-account/user Bearer token or Basic credentials, plus request and response bodies over the REST API and long-lived WebSocket streams used for exec, attach, port-forward, and watch operations, which the intermediary can also modify (VI:H). The library ships as the Composer package maclof/kubernetes-client (CPE cpe:2.3:a:maclof:kubernetes-client:*:*:*:*:*:*:*:*, wildcarded, i.e., version matching must be done by package version rather than CPE range).
Know when Kubernetes gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
On-path interception is required (AC:H); the attacker needs no credentials of their own (PR:N); captured tokens and tampered traffic yield high C and I, with no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
Applications using the maclof/kubernetes-client PHP library versions 0.17.0 through 0.31.x may expose Kubernetes API credentials and traffic when kubeconfigs omit certificate-authority-data and connect over HTTPS, because TLS verification is silently disabled. The risk is concentrated on deployments where an attacker already holds a man-in-the-middle position to the Kubernetes API server, potentially enabling API server impersonation, Bearer token or Basic credential theft, and REST/WebSocket tampering. Leadership should prioritize remediation because compromised Kubernetes credentials can provide broad access to production clusters and sensitive workloads; there is no public exploit identified at time of analysis.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
EUVD-2026-92155
GHSA-52r7-jqcr-m8h9
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB