A missing authorization flaw (CWE-862) was found in Kiali. Three Kiali Server API endpoints returned data about namespaces the caller has no RBAC access to, and the openshift authentication strategy accepted tokens with zero namespace access:

1. GET /api/clusters/health?namespaces=<ns>: with the health cache enabled (kiali_internal.health_cache.enabled, on by default since v2.22.0), the ClusterHealth handler only restricted the namespace list to the caller's accessible namespaces when the namespaces parameter was empty. Any authenticated caller could read the app, Service and workload names, replica counts, and request and error rates of any namespace. Per-finding CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3).

2. GET /api/namespaces/<ns>/pods/<prefix>/logs?logType=ztunnel: StreamPodLogs read the logs of every ztunnel pod with Kiali's ServiceAccount and filtered them with regular expressions built from the namespace and pod name in the URL. Neither the handler nor the business layer checked the caller's access to the namespace, and the filter expressions had no end anchor, so a single-letter pod name, or a namespace name that is a prefix of another namespace, matched other tenants' lines. The response exposes source and destination pods and namespaces, SPIFFE identities, addresses, byte counts and durations. Per-finding CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3).

3. GET /api/namespaces/<any>/pods/<ztunnel-pod>/config_dump_ztunnel: ConfigDumpZtunnel fetched the ztunnel configuration dump with Kiali's ServiceAccount without any namespace access check, unlike the Envoy ConfigDump handler which does check. The dump lists every workload, Service and policy in the mesh. Per-finding CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3).

A related gap: Kiali's RBAC documentation states that login is rejected for users who cannot see any namespace, but only the OpenID strategy enforced this. With the openshift strategy, any valid OpenShift token was accepted, including ServiceAccount tokens with no RoleBindings, which makes all three findings reachable by any token holder. This gap is not separately scored: without it an attacker still needs a token with access to at least one namespace, which remains PR:L.

Impact is confidentiality only. No secrets or traffic content are exposed and nothing can be changed. A stricter reading could argue S:C (5.0 per finding) because the data is fetched with Kiali's cluster-wide ServiceAccount across the tenant RBAC boundary, or C:H for finding 3 (6.5) because it discloses the full mesh configuration in a single request. The conservative primary flaw score is 4.3.

Affected versions:
- The ztunnel configuration dump arrived in Kiali v2.3.0 (upstream PR #7970).
- ztunnel log lines read with Kiali's ServiceAccount arrived in v2.5.0 (upstream PR #8046).
- The health cache, on by default, arrived in v2.22.0 (upstream PR #9082).
Therefore, of the Kiali versions shipped in Red Hat OpenShift Service Mesh 3 (2.4, 2.11, 2.17, 2.22, 2.27): all have finding 3; 2.11 and later have findings 2 and 3; 2.22 and later have all three. Kiali 1.73 predates all three.

Upstream fix: kiali/kiali PR #10437 "Enforce namespace authorization on health, ztunnel logs and ztunnel config dump APIs", merged 2026-10-26 (commit 9050b8f). The fix validates requested namespaces against the caller's RBAC and fails closed on the health endpoint, checks namespace access and anchors the ztunnel filter expressions on the logs endpoint, checks namespace access and filters the dump to the caller's accessible namespaces on the config dump endpoint, and rejects zero-namespace tokens in the openshift auth strategy.

Reported by Daniel Wallin (Conoa) via PSIRTSUPT-26414 on 2026-10-23. All findings were verified against the vulnerable code at upstream commit df5903b, and the filter bypass for finding 2 was reproduced by executing the vulnerable filter code directly.