CVE-2026-92615
Description
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.
Statement
Exploitation requires a multi-tenant deployment where at least two organizations use git-backed configuration providers concurrently. The attacker must be a fleet administrator (able to create Repository resources with custom TLS settings), must control or operate an external git server to receive misdirected credentials, and must win a race condition with the victim's concurrent git clone. In single-organization deployments, the attacker already holds the same privileges as the victim, so the race provides no meaningful privilege escalation.
Mitigation
There is no application-level workaround that fully eliminates this race condition without a code change. The following deployment-level measures reduce exposure in multi-tenant environments:
- Avoid mTLS client certificates for git repositories: If tenant Repository resources do not supply client TLS certificates (httpConfig.tls.clientCertificate), the most sensitive data (client private key material) is absent from the global transport and cannot leak.
- Avoid skipServerVerification: Do not set httpConfig.skipServerVerification: true on any Repository resource. This prevents a tenant's InsecureSkipVerify=true from propagating to other tenants' clones, which would otherwise allow an on-path attacker to serve malicious configuration.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 6.6 | N/A | 6.6 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | High | N/A | High |
| Privileges Required | High | N/A | High |
| User Interaction | None | N/A | None |
| Scope | Changed | N/A | Changed |
| Confidentiality | High | N/A | High |
| Integrity Impact | Low | N/A | Low |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N
cve.org: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N
Red Hat CVSS v3 Score Explanation
Corrected from reconciliation - matches real FIND-002
Understanding the Weakness (CWE)
Integrity,Availability
Technical Impact: Modify Application Data; DoS: Instability; DoS: Crash, Exit, or Restart
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
