CVE-2026-50192 in kerberos-io
Summary
by MITRE • 08/21/2026
Kerberos Agent is an open source video (surveillance) management agent. Prior to version 3.6.26, the Kerberos Hub upload path sends the agent's Hub credentials in the custom `X-Kerberos-Hub-PrivateKey` and `X-Kerberos-Hub-PublicKey` request headers to the operator-configured Hub URL (`config.HubURI`). The HTTP client used (`&http.Client{}` in `UploadKerberosHub`) is constructed without a `CheckRedirect` policy, so it follows HTTP redirects automatically. Go's `net/http` strips only sensitive headers (`Authorization`, `Cookie`, `WWW-Authenticate`) on a cross-host redirect; it does not strip custom headers such as `X-Kerberos-Hub-PrivateKey`. As a result, if the configured `HubURI` returns a cross-host 30x redirect, the Hub private key is forwarded verbatim to the redirect target, disclosing the credential to an unintended third party. Version 3.6.26 fixes the issue by implementing the `CheckRedirect` strip plus a cross-host regression test is provided to the maintainer through the advisory's private temporary fork.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Kerberos Agent versions prior to 3.6.26 represents a critical information disclosure flaw rooted in improper handling of HTTP redirects and sensitive header propagation. As an open-source video surveillance management agent, Kerberos Hub relies on secure communication channels between the local agent and a remote hub server for configuration updates and data synchronization. The core technical deficiency lies within the `UploadKerberosHub` function, which utilizes Go's standard library http.Client to transmit credentials to a user-configured endpoint defined by config.HubURI. Specifically, the agent includes custom HTTP headers named X-Kerberos-Hub-PrivateKey and X-Kerberos-Hub-PublicKey in every request made during this upload process. These headers carry cryptographic material essential for authenticating the agent to the hub service, making them high-value targets for attackers seeking to impersonate legitimate agents or decrypt sensitive surveillance data streams.
The operational mechanism of the flaw exploits a default behavior in Go's net/http package regarding HTTP redirection policies. By default, when an http.Client encounters a 30x redirect response without a custom CheckRedirect policy defined, it automatically follows the redirect to the new location specified by the Location header. While Go’s implementation is designed to strip certain sensitive headers such as Authorization and Cookie during cross-host redirects to prevent credential leakage, this protection mechanism does not extend to custom or application-specific headers. Consequently, if an attacker can manipulate the HubURI configuration or intercept traffic to force a redirect from the intended hub server to a malicious domain under their control, the X-Kerberos-Hub-PrivateKey header is transmitted verbatim to the unintended third party. This behavior effectively bypasses standard security expectations regarding credential isolation during redirection events.
The impact of this vulnerability is severe due to the nature of the exposed credentials. The private key contained within the X-Kerberos-Hub-PrivateKey header serves as a primary authentication factor for the agent-hub relationship. Disclosure of this key allows an attacker with network access or control over DNS or proxy configurations to perform man-in-the-middle attacks, impersonate the Kerberos Agent, and potentially gain unauthorized access to the surveillance management platform. This could lead to the exfiltration of video feeds, manipulation of recording schedules, or complete compromise of the physical security infrastructure managed by the system. The risk is exacerbated in environments where dynamic configuration updates are permitted without strict validation of redirect targets, as even a transient misconfiguration can result in permanent credential exposure if the malicious endpoint logs and stores the received headers.
From a classification perspective, this vulnerability aligns with CWE-201: Information Exposure Through Sent Data, specifically highlighting how sensitive information is inadvertently transmitted to unauthorized parties due to improper handling of HTTP protocols. It also relates closely to CWE-643: Improper Mitigation for Cross-Site Request Forgery Vulnerabilities in the context of header leakage during redirects, although it is primarily an authentication credential exposure issue rather than a request forgery vector. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1502.001: Steal or Forge Authentication Certificates via Cross-Site Request Forgery, as the attacker leverages the victim's authenticated session and credentials through redirect manipulation to achieve unauthorized access. The lack of explicit redirection policy enforcement is a common pattern in applications that rely on default library behaviors without considering edge cases involving external redirects.
The remediation for this issue involves implementing a custom CheckRedirect function within the http.Client configuration used by the UploadKerberosHub method. This function must inspect each request during the redirect chain and explicitly strip sensitive headers, including X-Kerberos-Hub-PrivateKey and X-Kerberos-Hub-PublicKey, whenever the host of the new URL differs from the original request's host. Alternatively, developers can configure the client to disallow redirects entirely if cross-host redirection is not a functional requirement for the hub communication protocol. Version 3.6.26 addresses this by introducing such a CheckRedirect policy that sanitizes headers on cross-host transitions and includes regression tests to prevent future reintroduction of this flaw. Organizations running affected versions should immediately upgrade to the patched release or apply manual code modifications to enforce strict header stripping during redirects, ensuring that cryptographic credentials remain confined to trusted domains only.