# GHSA-c534-2w9c-x7fm: Kite Kubernetes proxy path traversal allows authenticated users to bypass RBAC and read cluster-wide resources

> Authenticated users can bypass RBAC via path traversal to read cluster-wide secrets using Kite's service account.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Jul 2026
- **Also known as:** GO-2026-6105

## What is GHSA-c534-2w9c-x7fm?

GHSA-c534-2w9c-x7fm is a path traversal vulnerability in github.com/zxh326/kite, published on 24 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

## Summary

Kite versions 0.6.9 through 0.14.0 authorize Kubernetes proxy requests against the pod or service identified by the original route parameters. Encoded path traversal segments can cause the upstream URL to resolve to a different Kubernetes API endpoint after authorization.

## Impact

An authenticated user with `get` permission on pods or services in one namespace can cause Kite to issue GET requests to Kubernetes API endpoints outside that namespace using Kite's service account.

With Kite's default Helm RBAC configuration, this allows cluster-wide resource disclosure, including Secrets. The validated impact is confidentiality only; resource modification and denial of service were not demonstrated.

Deployments using a restricted Kite service account are affected only up to the permissions granted to that service account.

## Technical details

The authorization check is performed against the original namespace and kind route parameters. The proxy path is subsequently decoded and passed to `url.JoinPath`, which resolves `..` segments and can produce an upstream URL outside the authorized pod or service proxy prefix.

Two input locations were affected:

1. Encoded traversal segments in the proxy catch-all path.
2. Encoded traversal and slash characters in the resource name.

## Reproduction

1. Create a user with a role granting only `pods:get` in namespace `default`.
2. Create any pod in `default` (e.g. `nginx`).
3. Send the following request (auth cookie required):

```bash
curl --path-as-is --cookie "auth_token=<JWT>" \
  'http://<kite-host>/api/v1/_clusters/<cluster>/namespaces/default/pods/nginx/proxy/%2e%2e/%2e%2e/%2e%2e/%2e%2e/kube-system/secrets'
```

## Patches

Fixed in Kite 0.14.1.

- https://github.com/kite-org/kite/releases/tag/v0.14.1

## Workarounds

Upgrade to 0.14.1 or later.

If upgrading is temporarily impossible, reject encoded dot segments and encoded slashes at the reverse proxy and restrict Kite's Kubernetes service account permissions. Reverse-proxy normalization should not be treated as a permanent fix.

## Which versions are affected by GHSA-c534-2w9c-x7fm?

3 open source packages ship an affected version, including github.com/zxh326/kite.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/zxh326/kite` | Go | From 0.6.9 | 0.14.1 |
| `github.com/zxh326/kite` | Go | From 0.6.9 | 0.14.1 |
| `github.com/zxh326/kite` | Go | From 0.6.9 | 0.14.1 |

## How do I fix GHSA-c534-2w9c-x7fm?

Upgrade github.com/zxh326/kite to 0.14.1 or later.

## Is GHSA-c534-2w9c-x7fm being exploited?

There is no known exploitation of GHSA-c534-2w9c-x7fm in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-c534-2w9c-x7fm and fix it if it is affected.

What it is: GHSA-c534-2w9c-x7fm is a path traversal vulnerability in github.com/zxh326/kite, published on 24 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-c534-2w9c-x7fm in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/zxh326/kite (Go): affected from 0.6.9; fixed in 0.14.1
- github.com/zxh326/kite (Go): affected from 0.6.9; fixed in 0.14.1
- github.com/zxh326/kite (Go): affected from 0.6.9; fixed in 0.14.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-c534-2w9c-x7fm/ (Markdown: https://insights.sbomify.com/GHSA-c534-2w9c-x7fm/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-c534-2w9c-x7fm

---
From sbomify Insights: https://insights.sbomify.com/GHSA-c534-2w9c-x7fm/
Summaries are generated and may contain mistakes; the official description above is the record.