GHSA-h5gx-45rj-2h5j Kerberos Hub private key (X-Kerberos-Hub-PrivateKey) leaked to cross-host redirect target due to redirect-following HTTP client without CheckRedirect
SummaryThe 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 (CWE-200 / CWE-522).ImpactThe Kerberos Hub private key (a long-lived secret authenticating the agent to Kerberos Hub) is leaked to an attacker-controlled host whenever the configured `HubURI` issues a cross-origin redirect. `HubURI` is operator configuration (`models.Config.HubURI`, JSON `hub_uri`); an open redirect on that host, a compromised/hijacked Hub deployment, a DNS/BGP hijack, or a malicious URL supplied in the agent config causes the secret to be exfiltrated. The leaked private key (together with the public key, which is forwarded in the same request) grants the attacker the agent's access to Kerberos Hub, including the ability to upload/impersonate the device.Vulnerable code (file:line)`machinery/src/cloud/kerberos_hub.go` — the custom auth headers are set on a request to the operator-configurable `config.HubURI`, and the client follows redirects (no `CheckRedirect`):`HubURI` is operator configuration:Attack scenarioAn operator configures the agent with a `hub_uri`.That host (or a host reachable from it via redirect) responds to `/storage/upload` with `302 Found` to `https://attacker.example/...`.`client.Do(req)` follows the redirect and re-sends the request, including `X-Kerberos-Hub-PrivateKey` and `X-Kerberos-Hub-PublicKey`, to `attacker.example`.The attacker captures the Hub credentials.Proof of conceptDriver built against the verbatim pinned `kerberos_hub.go` from v3.6.25. The exported `cloud.UploadKerberosHub` is invoked. Two hostnames resolve to local test servers so `net/http` treats the 302 as a genuine cross-host redirect.End-to-end reproductionPinned to `github.com/kerberos-io/agent/machinery@v3.6.25`. Verbatim `kerberos_hub.go` from that tag. Captured stdout:The negative control on the same bare client and same cross-host redirect shows the standard `Authorization` header is stripped by `net/http`, while the custom `X-Kerberos-Hub-PrivateKey` is forwarded — confirming the leak is specific to the custom-named auth header.Suggested fixSet a `CheckRedirect` policy on the client used in `UploadKerberosHub` (and the other Hub helpers in this file) that strips the `X-Kerberos-Hub-PrivateKey` / `X-Kerberos-Hub-PublicKey` headers (and any other custom auth headers) when the redirect target host differs from the original request host:A regression test should assert that after a cross-host redirect the `X-Kerberos-Hub-PrivateKey` header is absent at the final host, and that same-host redirects still carry it.Fix PRA fix PR implementing the `CheckRedirect` strip plus a cross-host regression test is provided to the maintainer through the advisory's private temporary fork.CreditReported by tonghuaroot.
CVSS v4.0 score: 6.9