CVE-2026-92615 in Advanced Cluster Management for Kubernetes
Summary
by MITRE • 09/16/2026
A flaw was found in flightctl. The configureRepoHTTPSClient() function in the device-render worker builds a per-repository tls.Config (which may include InsecureSkipVerify, a custom CA bundle, or tenant-supplied mTLS client certificates) and installs it into go-git's process-global client.Protocols map via gitclient.InstallProtocol("https", ...). Because the worker renders devices for multiple organizations concurrently from a shared goroutine pool, whichever tenant's repository configuration is written last wins for all in-flight git.Clone calls. This race condition can cause one tenant's TLS settings, including InsecureSkipVerify or mTLS client credentials, to leak into another tenant's git operations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in flightctl represents a critical security flaw rooted in improper state management within the device-render worker component. Specifically, the configureRepoHTTPSClient function is responsible for constructing per-repository TLS configurations that may include sensitive settings such as InsecureSkipVerify flags, custom Certificate Authority bundles, or tenant-supplied mutual Transport Layer Security client certificates. These configurations are intended to be isolated on a per-tenant basis to ensure strict multi-tenancy boundaries and secure communication with remote repositories. However, the implementation flaw lies in how these configurations are applied to the underlying git library used by the system.
The core technical issue involves the installation of the TLS configuration into go-git's process-global client.Protocols map via a call to gitclient.InstallProtocol("https", ...). This method registers the HTTPS protocol handler with global state rather than passing the configuration through instance-specific parameters or thread-local storage. In a properly designed system, each concurrent operation would maintain its own isolated context for network connections and security policies. Instead, by modifying a process-wide registry, the application creates a shared mutable state that is susceptible to race conditions when multiple operations execute simultaneously.
The operational impact of this flaw is exacerbated by the concurrency model employed by the device-render worker. The system utilizes a shared goroutine pool to render devices for multiple organizations concurrently. Because these goroutines operate in parallel and access the same global protocol registry, a classic time-of-check-to-time-of-use race condition emerges. When one tenant's repository configuration is processed last among concurrent operations, its TLS settings overwrite those of other tenants currently executing git.Clone calls. This means that the security context intended for one organization is inadvertently applied to another organization's data retrieval processes.
This race condition leads to severe confidentiality and integrity risks within a multi-tenant environment. If Tenant A's configuration includes InsecureSkipVerify set to true, it may overwrite Tenant B's secure TLS settings during concurrent execution. Consequently, Tenant B's git operations might proceed without verifying the server's certificate identity or validity, exposing sensitive repository data to man-in-the-middle attacks and credential theft. Furthermore, if tenant-supplied mutual Transport Layer Security client certificates are involved, there is a risk that one tenant's private keys could be used in contexts where they should not apply, potentially leading to unauthorized access to resources belonging to other tenants or the leakage of cryptographic material across organizational boundaries.
From an industry standards perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resource with insufficient synchronization. The failure to isolate state between logical users in a multi-threaded environment is a fundamental design error that undermines the principle of least privilege and isolation required for secure software architecture. Additionally, the potential for unauthorized access due to misconfigured security controls relates to CWE-749, which pertains to exposure of dangerous method or property to an actor with insufficient privileges. In terms of attack vectors, this scenario reflects aspects of ATT&CK technique T1530, Data from Information Repositories, where attackers might exploit such a flaw to access data they are not authorized to view by manipulating the execution context of git operations.
To mitigate this vulnerability, the immediate remediation requires refactoring the go-git integration to avoid using global state for protocol-specific TLS configurations. The solution should involve passing the tls.Config directly through the cloning options or request context rather than installing it into a process-wide map. This ensures that each git operation retains its specific security parameters regardless of concurrent activity from other tenants. Implementing strict synchronization mechanisms, such as mutexes around any global state modification, is insufficient for this type of architectural flaw because it introduces performance bottlenecks and does not guarantee isolation if the design remains fundamentally shared-state based.
Long-term mitigation strategies should include adopting a zero-trust architecture where every request carries its own security context without relying on ambient process-level settings. Code reviews must specifically target concurrency patterns involving global mutable state, particularly in multi-tenant applications. Automated testing suites should incorporate stress tests that simulate high-concurrency scenarios to detect race conditions before deployment. Additionally, enforcing strict separation of tenant contexts at the application layer, rather than relying solely on network-layer security configurations, will provide defense-in-depth against such logical flaws. Regular auditing of third-party library usage is also essential, as libraries like go-git may expose global APIs that are dangerous in concurrent multi-tenant environments if not handled with extreme care and proper encapsulation techniques.