CVE-2026-105223: a PHP Kubernetes client and missing TLS verification

CVE-2026-105223, published on 5 October, covers the PHP library maclof/kubernetes-client from 0.17.0 up to, but excluding, 0.32.0. When parsing kubeconfig without certificate-authority-data, the client could disable certificate verification despite an HTTPS address and disregard insecure-skip-tls-verify.

This is a new record for a previously reported bug. The researcher filed the issue on 18 June; the 0.32.0 release dated 2 September lists a fix for the unsafe fallback when CA data is absent. It does not establish a vulnerability in every Kubernetes client or a new cluster breach.

An important difference in the scope descriptions

The original researcher report identifies the WebSocket path, where certificate and server-name verification were disabled. It lists operations including exec, attach and port-forward, while marking ordinary PSR-18 HTTP CRUD requests as unaffected by the reported issue. The CVE record uses broader wording covering WebSocket or REST.

Assess the transport, version and configuration your application actually uses. We state the discrepancy explicitly instead of extending one description to every operation. An attacker on the connection path can impersonate the API server and capture credentials. Subsequent actions depend on their permissions; a stolen token does not automatically grant cluster-admin access.

Why HTTPS alone does not settle the assessment

Breachroad’s conclusion is that a connection review should cover encryption and verification of the recipient’s identity. The port number, URL scheme and a successful connection do not provide enough evidence that verification is working.

Ask the team to identify the source of CA trust, whether the server name is checked, and whether a certificate error prevents credentials from being sent. If the application has several ways to communicate with the API, assess each one it uses. A successful check of one HTTP client does not complete the review of a different transport.

Five actions for the integration owner

1. Identify the dependency. Check the package in the dependency lock file and the version inside the running image. Include administrative tools and supporting services.
2. Deploy the fix. Choose a supported version containing the 0.32.0 repair. The release also changes repository classes; review direct imports and custom extensions before upgrading.
3. Verify connection rejection. In an isolated environment with harmless test data, confirm that an untrusted certificate and a server-name mismatch stop the communication path under assessment.
4. Correct the trust configuration. Supply the appropriate CA and server-name settings. Do not resolve certificate failures by turning verification off.
5. Assess credentials. Establish token scope, recipients and the period of use. If there is evidence suggesting interception, invoke the incident process, replace credentials and review API operations.

This is Breachroad’s proposed verification procedure. We do not recommend interception tests with real production tokens or treating installation of an affected version alone as proof of credential disclosure.

Training scenario: resource listings and a console both work

In our fictional example, a dashboard retrieves resource lists correctly through an HTTP client. Its separate console function uses WebSocket. The tester checked only the listing, so the report does not establish whether the console rejects an invalid certificate.

The team must supply the missing evidence and identify the owners of the transport and its configuration. The intended result is a map of connections and rejection conditions, rather than a demonstration involving a captured secret. The same review approach can be applied to other integrations.

Cybersecurity training for IT teams helps teams rehearse configuration reviews and patch ownership. Supporting material covers TLS, mTLS and PKI and Kubernetes RBAC permissions.

Sources and Breachroad conclusions

Dates and affected versions come from the CVE record. The researcher describes the WebSocket path; the project documents the fix and migration requirements. We preserve the difference in scope between the sources. The action plan and fictional scenario are Breachroad recommendations. Sources were checked on 5 October 2026.